Доклад Алексея Лесовского про то, что нового есть в PostgreSQL в плане мониторинга.

Охватывать Алексей будет 13 и 14 версии. Далее от его лица.

Привет! Меня зовут Павел Агалецкий, я старший инженер в команде архитектуры. Одна из областей ответственности нашей команды — синхронное (RPC) и асинхронное взаимодействие между сервисами. 

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

В процессе обучения аналитике данных у человека неизбежно возникает вопрос о миграции данных из одной среды в другую. Поскольку одним из необходимых навыков для аналитика данных является знание SQL, а одной из наиболее популярных СУБД является PostgreSQL, предлагаю рассмотреть импорт и экспорт данных на примере этой СУБД.

В своё время, столкнувшись с импортом и экспортом данных, обнаружилось, что какой-то более-менее структурированной инфы мало: этот момент обходят на всяких там курсах по аналитике, подразумевая, что это очень простые моменты, которым не следует уделять внимание.

В данной статье приведены примеры импорта в PostgreSQL непосредственно самой базы данных в формате sql, а также импорта и экспорта данных в наиболее простом и распространенном формате .csv, в котором в настоящее время хранятся множество существующих датасетов. Формат .json хоть и является также очень распространенным, рассмотрен не будет, поскольку, по моему скромному мнению, с ним все-таки лучше работать на Python, чем в SQL.

Модуль машинного обучения в Nemesida WAF - это не маркетинг, призванный повышать продажи за счет популярной концепции, а мощный инструмент, с помощью которого нам удалось перекрыть недостатки сигнатурного анализа и повысить точность выявления атак до 99.98% на боевом трафике. Что ж, пришло время пояснить за ML, DDoS L7, ATO и атаки ботов.

Все хотят повышения зарплаты. Как правило – себе. Это совершенно нормально – своя рубашка ближе к телу. Бывает, что один добивается повышения себе, а прицепом достаётся и остальным. Однако, как вы, наверное, знаете, так случается не очень часто – счастливчика обязательно попросят никому ничего не рассказывать.

Собственно, это одна из причин жуткой нелюбви начальников к индивидуальным договорённостям по зарплате. Тот же Артемий Лебедев давно говорил, что запретил сотрудникам рассказывать друг другу, кто сколько получает – обязательно кто-нибудь придёт и скажет «а чё он больше получает?».

Вторая причина ещё банальнее: для начальника повышение зарплаты одному человеку – довольно жуткий геморрой (если он не собственник, разумеется). Чем больше компания и ниже начальник, тем процесс сложнее. Проситель-сотрудник автоматом превращает в просителя самого начальника. Тот должен идти и просить чуть ли не для себя. В ответ, с высокой вероятностью, начальник получит лекцию о собственной некомпетентности, неумении «строить команду» и использовать нематериальные методы мотивации. Вон Коля, начальник соседнего отдела, молодец – просто купил три настолки, и никто больше не ноет.

Теперь давайте зайдём с другой стороны и посмотрим на реальную статистику не индивидуальных, а массовых улучшений условий труда – и зарплаты, и всего прочего. Когда, почему, в какой момент они чаще всего случаются? Не будем рассматривать сказки о великих гигантах, которые просто индексируют зарплату на уровень инфляции. Посмотрим на что-нибудь более приземлённое.

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

Если вы не понимаете, о чём идет речь, то рекомендую ознакомиться с первыми частями: часть 1, часть 2.

Повторный дисклеймер. Это только мой опыт работы с клиентами подобного типажа. Я не развешиваю ярлыки и не создаю стереотипы. Я просто делюсь осмыслением своего практического опыта и рекомендациями, которые показали определенную эффективность. Точка.

Всем привет! Для тех, кто уже читал мои посты о блокчейне хочу сказать, что рад вас видеть снова на своей странице. Для тех, с кем мы еще не знакомы, меня зовут Валерий, я junior developer в западном стартапе, приятно познакомиться. 

Я как-то уже писал о том, что мы собираем свою “Википедию” о технологиях на крипторынке. Сейчас мой фокус внимания смещен на все составляющие блокчейна, я продвигаюсь снизу вверх, чтобы лучше понять, как это все работает. И вот мне в связи с работой постоянно попадались некоторые обозначения, которые мне поначалу казались синонимами. 

Речь идет о протоколах или алгоритмах консенсуса, на которых, собственно, и работает блокчейн. Но этим все не ограничивается, с этими протоколами связано немало терминов, объясняющих их работу. Честно говоря, чтобы изучить протоколы и их составляющие, я потратил довольно много времени и прошерстил немало ресурсов. И я подумал, что добру зря пропадать и решил сделать новую публикацию с моим исследованием.

Привет, друзья!

В этой статье я продолжаю (и заканчиваю) делиться с вами заметками о Docker.

Заметки состоят из 4 частей: 2 теоретических и 2 практических.

Если быть более конкретным:

• первая часть посвящена Docker, Docker CLI и Dockerfile;
• во второй части рассказывается о Docker Compose;
• в третьей части мы разрабатываем приложение, состоящее из трех сервисов: клиента на React, админки на Vue и сервера на Express, и базы данных PostgreSQL, взаимодействие с которой осуществляется с помощью Prisma.

В этой заключительной части мы "контейнеризуем" наше приложение.

Репозиторий с кодом приложения.

Если вам это интересно, прошу под кат.

Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.

Статья расскажет, как правильно оформить ваши мысли, и что должно содержать качественное архитектурное решение. Статья не научит делать архитектуру.

Статья будет полезна:

• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;

• Архитекторам, чтобы улучшить качество выпускаемых документов;

• Главным архитекторам с целью посмотреть «а как там у них».

Сегодня мы с вами рассмотрим скрипт для автопостинга записей с сайта в сообщество Вконтакте. Вы научитесь работать с API вконтакте, создавать свои приложения, писать парсеры для отправки запросов в Вконтакте. Всю работу мы будем прописывать на языке PHP.

Естественным источником информации в банке о покупках клиента являются карточные транзакции – любые операции, проводимые по дебетовым или кредитным картам. При этом денежные операции клиента не ограничиваются транзакциями, проводимыми с помощью карт. Оплата ЖКХ, оплата образования, крупные покупки и другие денежные переводы – это примеры транзакций, которые никак не привязаны к карте клиента, но при этом они ассоциируются с другой банковской сущностью – расчетным счетом. 

Про то, как мы в Альфа-Банке применяем карточные транзакции в моделировании, мы уже рассказывали в этом посте. Логичным развитием идеи использования карточной транзакционной истории клиента является использование данных, которые содержатся в клиентской истории транзакций расчетного счета.

Как создать telegram bot на C# быстро?

В этой статье мы рассмотрим заготовку для создания telegram бота на C#. В связи с последними обновлениями TelegramBotAPI, большая часть удачных с моей точки зрения публикаций на эту тему несколько устарело. Потому предлагаю разобраться в этой теме.

15 лет назад DevOps начинался в попытке “подружить” разработку и эксплутацию — через культуру, обмен знаниями и совместную работу. Затем быстро развернулся в сторону ускорения поставки изменений из разработки в продакшн (активность Lean Value Stream Mapping), продолжился в понимание того, что программисты создают не просто код в репозитории (и даже не протестированный код в репозитории), а работающее приложение в продакшне (практики Observability и SRE). И последние несколько лет DevOps перешел к рассмотрению взаимодействия команд на масштабе (фреймворк Team Topologies).

Что при этом менее заметно, так это происходящая одновременно с этим эволюция корпоративной архитектуры:

Понимание того как Kubernetes обрабатывает контейнеры дает большую гибкость при создании пользовательских конфигураций под конкретные нужды.

Kubernetes позволяет выполнять много полезной работы без глубокого понимания деталей. Утилита командной строки kubectl и дашборды в Openshift помогают управлять вашими контейнерами. Однако, как только вы заглянете глубже в Kubernetes все может быстро усложниться.

Тем не менее, понимание того, как основные части взаимодействуют друг с другом, является важным для главного архитектора, который использует Kubernetes в своих проектах. Проведем аналогию с обычным архитектором: для проектирования небоскребов важно знать прочность на растяжение железобетона в сравнении с балками из чистой стали. Также полезно понимать как работают системы отопления, вентиляции и кондиционирования воздуха.

Такая аналогия правдива и для работы с Kubernetes. Просто сказать: "Давайте оставим это на усмотрение разработчиков" - недостаточно, с таким же успехом можно предоставить выбор системы кондиционирования обычным рабочим со строительной площадки. За каждой хорошо спроектированной системой стоит как множество деталей, так и архитектор, который понимает их значение.

Для системного архитектора в IT важно понимать как Kubernetes создает и запускает контейнеры. Изучение контейнерной оркестрации необходимо по двум причинам. Во-первых, это хорошее знание для архитектора уровня компании (как для обычного архитектора знание систем кондиционирования). Во-вторых, понимание механизмов, благодаря которым Kubernetes создает и запускает контейнеры, позволяет настраивать пользовательские конфигурации кластеров Kubernetes для специфичных кейсов, но для этого необходимо понимать основы.

Во встроенном процедурном языке PL/pgSQL для СУБД PostgreSQL отсутствуют привычные операторы TRY / CATCH для для перехвата исключений возникающих в коде во время выполнения. Аналогом является оператор EXCEPTION.

До подобного момента надо ещё дожить, но однажды случается и такое. В один прекрасный день мне понадобилась БД с 1 триллионом записей. Причём, понадобилась на домашнем компьютере, где свободного места 700 гигабайт на двух дисках.

По счастью, моя БД не совсем обычная: размер записи всего 1 бит. В базе должны храниться данные о простых числах. Соответственно, вместо того, чтобы хранить сами числа, проще хранить один бит (1 - простое число, 0 - композитное). И тогда, чтобы хранить один триллион битов, нужно всего 116 ГБайт.

Однако сделав такой файл, мы получили только лишь хранилище, но не собственно БД. Нам нужен код, который будет записывать и считывать данные. Традиционный FileStream был отброшен сразу, по причине его медленности. Постоянное чередование Seek и чтения/записи по 1 байту даёт результат примерно в 100 раз худший, чем сопоставленные в памяти файлы, опытом использования которых я и хочу поделиться в этой статье.

• Метод фазово-амплитудной интерполяции (ФАИ)

• Точное определение частоты, амплитуды и фазы гармоник сигнала

• Выявление резонансов

Алгоритм быстрого преобразования Фурье (БПФ) - важный инструмент для анализа и обработки сигналов различной природы.

Он позволяет реконструировать амплитудный и фазовый спектры сигнала в частотной области представления по его амплитудным отсчётам во временной, при этом метод вычислительно оптимизированный при скромном расходе памяти.

Хотя в процессе преобразования никакая информация о сигнале не утрачивается (вычисления обратимы до округлений) алгоритму присущи некоторые особенности, которые затрудняют высокоточный анализ и тонкую обработку результатов в дальнейшем.

В статье представлен действенный способ преодоления таких "неудобных" особенностей алгоритма.

Читать на английском