В апреле этого года мы, команда производительности из Postgres Professional, совместно с коллегами из Selectel решили протестировать несколько дистрибутивов PostgreSQL и узнать, как они себя поведут на разных архитектурах. С результатами можно ознакомиться в этой статье, но, как сразу было верно отмечено читателями, там был один важный косяк –  мы не сравнили производительность ванильного PostgreSQL с применением всем известных настроек по улучшению производительности и Postgres Pro Enterprise из коробки as is. Терпеть такое не было решительно никакой возможности, поэтому сегодня будет продолжение истории и ответ на важный для многих вопрос: «А есть ли у нашего форка хоть какое-то преимущество перед бесплатной ваниллой?» Или мы просто накатили общеизвестный конфиг и занимаемся импортозаместительным переклеиванием наклеек?

Еще в 1940-х годах, Джон фон Нейман и Станислав Улам изобрели моделирование Монте-Карло или численный метод Монте-Карло. Они назвали его в честь известного места азартных игр в Монако, поскольку этот метод имеет те же случайные характеристики, что и игра в рулетку.

Методы Монте-Карло представляют собой широкий класс вычислительных алгоритмов, которые полагаются на повторяющуюся случайную выборку для получения численных результатов. Основная концепция заключается в использовании случайности для решения проблем, которые в принципе могут быть детерминированными. Численный метод Монте-Карло использует три класса задач, такие как оптимизация, численное интегрирование и генерация результатов на основе распределения вероятностей.

Метод Монте-Карло используется в реальной жизни, например, в задачах, связанных с физикой, создании искусственного интеллекта, прогнозировании погоды и так далее, а также имеет огромное применение в финансах, где числовой метод Монте-Карло используется для расчёта стоимости акций, прогнозировании продаж, управления проектами и многого другого.^[1]

Основное преимущество использования Монте-Карло заключается в том, что этот метод обеспечивает множество возможных результатов и вероятность каждого из большого пула случайных выборок данных, однако, метод зависит от предположений, и это иногда может быть сложной задачей. Некоторые другие преимущества Монте‑Карло: он изучает поведение системы без её построения, обеспечивает в целом точные результаты, по сравнению с аналитическими моделями, помогает обнаружить неожиданное явление и поведение системы, а также выполнить анализ «что, если». ^[2]

Статический анализ — это очень мощный инструмент, позволяющий следить за качеством кода. Предлагаем вместе попробовать написать простой Lua анализатор на Java, чтобы понять, как устроены статические анализаторы кода внутри.

Всем привет! Меня зовут Люба, и я инженер по тестированию в команде Ozon Partners Platform. Наша команда занимается поддержкой и развитием системы, предназначенной для развития сети пунктов выдачи Ozon. Одним из компонентов этой системы является Открытая карта.

Хочу рассказать, как мы научили автотесты находить на ней точки, подходящие для открытия нового ПВЗ.

В природе существуют два широкоизвестных метода ввода-вывода: блокирущий и неблокирующий. Отношение к блокирующему как правило пренебрежительное, мол, он для нубов, а серьезным людям использовать его не стоит.

В этой статье я разберу блокирующий, неблокирующий, а также квази-блокирующий методы. Примеры буду брать из приложений, которые разрабатывал в ходе собственной практики.

Так как микроконтроллеры предоставляют разработчику полную свободу во взаимодействии с железом, примеры я тоже буду давать для абстрактного усредненного микроконтроллера семейства stm32. Но и на прочих NXP философия примерно такая же.

В общем, хочу поделиться собственным опытом, но не откажусь и от совета в комментариях.

Привет, Хабр! Эта статья для тех, кто хочет понять, когда стоит использовать sync.Map, а когда достаточно обычной map с мьютексом.

В Каруне этот вопрос иногда возникал на код ревью, поэтому такая статья мне показалась полезной. TLDR: sync.Map лучше работает на задачах, где много операций чтения, и ключи достаточно стабильны.

Внутреннее устройство sync.Map

sync.Map — это потокобезопасная реализация мапы в Go, оптимизированная для определенных сценариев использования.

Основная структура sync.Map выглядит примерно так:

type Map struct {
    mu Mutex
    read atomic.Value // readOnly
    dirty map[interface{}]*entry
    misses int
}

type readOnly struct {
    m       map[interface{}]*entry
    amended bool
}

type entry struct {
    p unsafe.Pointer // *interface{}
}

Здесь мы видим несколько ключевых полей:

Алгоритм

Привет! Меня зовут Сергей Реусин и последние пять лет я занимаюсь эксплуатацией production-систем с непрерывной практикой инцидент-менеджмента. Каждый день, сталкиваясь с аномалиями и проблемами, невольно спрашиваешь себя: «Почему это происходит? А главное — как с этим дальше жить?». Три нелегких года работы в Купере ( ex СберМаркет), где мне доверили строить культуру инцидент-менеджмента, помогли мне утвердиться во мнении и подходах, которые действительно помогают справляться с подобными вызовами. О них и поговорим!

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

1. Определим, ради чего вся эта «доступность» и «стабильность» нужна

2. Попробуем устаканить терминологию, чтобы говорить на одном языке

3. Посмотрим на понятие системы с позиции устойчивости

4. Обратимся к историческому опыту

5. Изучим возможные паттерны отказов систем и способы их митигации

6. Визуализируем модель восприятия аномалий

7. Познакомимся с ключевыми личностями в подходах Resilience Engineering

Однажды мы решили, что грамотных инженеров эффективнее всего растить самим. Так 3 года назад родился Route 256 — курсы Ozon для разработчиков и тестировщиков уровней junior и middle.

Во время курса ведущие специалисты Ozon погружают в индустрию e-com, знакомят с актуальным стеком и бизнес-задачами. Самые успешные выпускники получают оффер в команду Ozon.

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

Привет, Хабр! На связи Виктор Сергеев, редактор «МТС Диджитал». Сегодня обсудим «большую чистку» ядра Linux.

Для начала стоит избавиться от поддержки десятков устаревших ARM-процессоров. Многие чипы почти не используются, смысла в их поддержке в ядре Linux все меньше. Но как их убрать, чтобы изменения прошли безболезненно для пользователей? У одного из самых известных контрибьюторов Linux Арндта Бергмана есть план. Подробности — под катом.

Данная статья является продолжением: PostgreSQL 16. Страницы и версии строк. Часть 3.

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

Уже много лет IT компании проводят алгоритмические собеседования при найме технических специалистов. Подход введенный в FAANG плавно перетек в большинство крупных компаний. Яндекс, Авито, Т-Банк и многие другие хотят проверить алгоритмические знания кандидатов. Но на практике такое собеседование оказывается бесполезным созвоном на 45 минут, который ничего не говорит о кандидате.

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

Но очень мало можно встретить критики и конкретного разбора проблем алгоритмических собеседований и их внедрения в воронку найма. Эта статья будет первой в цикле “в чем проблема алгоритмов”.

Кто-то может сказать: “О, человека не приняли в компанию из-за алгоритмов и он решил обидеться и сказать всем, что алгоритмы бесполезны”. Отчасти это так и было, но я решил не останавливаться на своем чувстве несправедливости и пошел дальше: адаптировал алгоритмы в компании, прошел все этапы в Google и даже решал алгоритмы на протяжении года.

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

Но все это отдельными статьями, ссылки на которые я приложу сюда позже.

Сейчас я просто хочу рассказать свою историю.

Пару статей назад я уже рассматривала один из алгоритмов Бойера-Мура, с помощью которого можно было найти подстроку в строке.

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

Предлагаю сразу использовать его на примере задачи «Majority Element» с leetcode.

Условие здесь: https://leetcode.com/problems/most-frequent-even-element/description/

Кстати, у меня есть телеграм-канал, где пишу подходы к решениям всяких задачек с LeetCode, там больше разборов конкретных задач, чем здесь, потому что не всегда нужна статья. В общем, если интересно - жду здесь - t.me/crushiteasy :)

Возвращаемся к Муру!

Кратко: на вход мы получаем массив, состоящий из чисел. Нужно найти число, которое встречается наибольшее количество раз. 

Не супер очевидно, но это число занимает больше половины элементов массива, т.е.

Недавно я захотел подкачать свои знания языка C. Я решил написать небольшой проект используя только стандартную библиотеку языка. Чтобы извлечь ещё больше пользы из данного проекта, я решил изучить новую для меня технологию. Этой технологией стал протокол прикладного уровня SMTP, а проектом – небольшой SMTP-сервер. Сегодня я расскажу, как работает протокол SMTP, а также как я реализовал сервер, работающий с ним.

Всем привет! Меня зовут Дмитрий Первушин, я лидер Python-компетенций трайба ИСУ в Сбере. 

Эта статья рассчитана на людей, которые уже знакомы с Python, хотя бы на уровне junior+. Я объясню, какие есть отличия и особенности в многопоточности, асинхронности и мультипроцессорности в Python, где и когда они используются. Как говорится в пословице: «Всё познаётся в сравнении», именно в таком стиле я подготовил примеры. Кроме этого, буду специально делать ошибки и рассматривать неправильные подходы, чтобы можно было сразу разобраться, убедиться и запомнить, почему так делать нельзя и какой другой подход в этом случае нужно использовать.

С ростом сложности ИТ-систем и задач аналитики изменяются требования и к возможностям инструментов. Для многих сценариев приоритетными становятся решения, которые могут работать как с историческими данными, так и с теми, которые обновляются в реальном времени. То есть аналитикам все чаще нужен инструмент, работающий на стыке возможностей транзакционных и аналитических (OLAP и OLTP) систем.

Меня зовут Николай Карлов. Я директор инновационных проектов в VK Tech. В этой статье я расскажу, что такое HTAP-системы, какие преимущества они предоставляют, и познакомлю с нашей колоночной СУБД Tarantool Column Store, которая реализует HTAP-обработку.

Статья подготовлена по мотивам вебинара «Анализируем данные в Real-time». Его вы можете посмотреть здесь.

Обратите внимание: в этой статье речь идёт об отладчиках, работающих с нативным кодом – например, GDB, LLDB, Visual Studio C++. Отладчики для управляемых и скриптовых языков работают примерно так же, но могут отличаться детали реализации.

Привет, меня зовут Елена Тихомирова, я работаю системным аналитиком в Платформе Сфера, разработке Холдинга Т1. Поделюсь своим опытом, полученным в одном из проектов, где я реализовала автоматизированную обработку входящей почты: пользователь отвечает на email-уведомление от help desk или трекера задач, обработчик извлекает из письма необходимые данные, обогащает их и передаёт соответствующему сервису для дальнейшей проверки и публикации.

Некорректное использование строк может стать настоящей ахиллесовой пятой защиты программы. Поэтому так важно применять актуальные подходы к их обработке. Под катом разберём несколько паттернов ошибок при работе со строками, поговорим о знаменитой уязвимости Heartbleed и узнаем, как сделать код безопаснее.