Алгоритм сортировочной станции (Shunting Yard) был предложен Дейкстрой ещё в 1961 году и служит для преобразования математических выражений из привычной всем инфиксной записи (где операторы стоят между операндами, как в 1 + 2 * 3) в постфиксную (обратную польскую нотацию, 1 2 3 * +), удобную для дальнейшего вычисления. Однако есть один важный момент, который почти всегда упускается или замалчивается: алгоритм предполагает, что входное выражение уже синтаксически корректно.

Ни в Википедии, ни в большинстве обучающих статей вы не встретите слов о том, что выражения вроде + (1 2, 3 * 4 + ) или sin(+) должны вызывать ошибку. В лучшем случае они просто не вычисляются (что будет понятно лишь на этапе обработки в обратной польской записи), в худшем – дают бессмысленный результат. Алгоритм продолжает работать, даже если выражение изначально некорректно – и мало кто задумывается, почему это плохо.

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

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

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

Чтобы решить эту проблему, разработаны специальные паттерны и протоколы управления распределёнными транзакциями. В этой статье детально рассмотрим ограничения классических ACID-транзакций в распределённой архитектуре, а также два подхода к распределённым транзакциям – сага (SAGA) и двухфазный коммит (2PC). Разберём мотивацию, принципы работы, преимущества и недостатки каждого, сравним их по критериям. Кроме того, обсудим альтернативные подходы, такие как TCC (Try-Confirm-Cancel), паттерн Outbox, а также кратко упомянем eventual consistency, транзакционные сообщения, инструменты вроде Atomikos и др. В завершение – практические рекомендации, как выбрать подходящий способ обеспечения согласованности в ваших микросервисах.

Вторая глава из цикла "Введение в ПЛИС". В ней мы переходим от общих понятий к практике — начинаем изучать язык Verilog, его базовые конструкции и принципы проектирования. Материал остаётся доступным для новичков, но потребует больше внимания к деталям.

Как превратить скучные слайды в интерактивную демонстрацию, где код можно запускать прямо на месте? В этой статье попробуем перенести презентацию в браузер, а затем — в «блокнот». Интерактивные среды, такие как Jupyter Notebook, Observable, Mathematica, WLJS Notebook, позволяют создавать живые презентации, лекции и наглядные материалы для коллег или студентов. Они незаменимы и для визуализации моделей, симуляций и любых данных.

Под катом — примеры, пошаговый разбор и демо вживую.

С вами снова Юля, системный аналитик из EvApps и мы продолжаем разбираться в технологии WebSocket. В первой части (WebSocket для начинающих системных аналитиков: просто о сложном. Часть 1), мы познакомились с основами WebSocket, а теперь давайте заглянем под капот реального сайта, например, криптобиржи. Попробуем понять, как работает этот сложный механизм: что происходит, когда вы видите мгновенно меняющиеся котировки и графики, и что происходит “за кулисами”.

«Вспоминаю, как в 7-м классе ничего не понимал, когда мы начинали разбирать тригонометрию. С учителем мы не смогли найти общий язык, поэтому к 8–9-му классу я был уверен, что никогда не буду заниматься математикой, а уж тем более сидеть по несколько часов в день, утыкаясь в учебники Беклемишева или Кожевникова и параллельно просматривая лекции Физтеха…»

Всем привет! Идею этой статьи я вынашивал довольно долго, пока не набрался опыта в том, что сейчас стало моей каждодневной практикой. Надеюсь, мой опыт поможет кому-то из вас комфортнее и эффективнее подойти к изучению математики (а может, и других наук). Предлагаю познакомиться:

Меня зовут Ренат, мне 23 года, я родился в Москве, окончил обычную школу и вплоть до 19 лет не понимал, чем хочу заниматься — что называется «что меня драйвит». Сейчас живу на Кипре, работаю тут аналитиком, продолжаю параллельно учиться в России и скоро заканчиваю там университет.

За последние несколько лет я успел поработать аналитиком в Ozon, затем продуктовым аналитиком в Тинькофф (ныне Т-банк), перешёл в лондонский стартап, а сейчас тружусь над проектами в сфере Trust & Safety. И вот в один прекрасный день я решился «серьёзно ботать математику»: уже несколько месяцев уделяю 10–15 часов в неделю задачам, лекциям и подготовке к поступлению в магистратуру (решая вступительные от МГУ, ВШЭ, МФТИ). Именно об этом пути — как я ищу мотивацию, борюсь с прокрастинацией и стараюсь не выгореть — я и хочу вам рассказать.

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных. Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​.

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации, лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

Каждый раз, когда меня спрашивают: «А как ты вообще пришел к этим заповедям?», я улыбаюсь и вспоминаю одну историю. Она началась не в IT, не в офисе и даже не за чашкой кофе (хотя кофе, конечно, был). Она началась там, где начинается всё важное — в голове одного человека, который однажды осознал, что его жизнь превратилась в бесконечный марафон без финишной черты.

Я программист. Меня всё время отвлекают, и я хочу об этом поговорить.

Вы когда-нибудь задумывались, что сильнее всего подрывает эффективность работы? Много чего. Но мы часто недооцениваем один фактор, который выделяется на фоне остальных.

Каждое короткое сообщение, которое вы отправляете коллеге в Slack, отнимает у него 23 минуты продуктивной работы. И это далеко не всё.

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

Программируемая Логика - увлекательный и своеобразный мир - к сожалению среди большинства из нас, знатоков Python, JS, Go, Java, C++ да и среди любителей Arduino и прочих микроконтроллеров она не так широко "распростирает свои руки".

Давно хотелось среди задачек и головоломок на "обычное" программирование внедрить на сайте и горстку упражнений из этой таинственной области. Мешало банальное отсутствие собственного опыта в ней (за исключением нескольких занятий по AHDL в далёкие вузовские годы).

Мотивация (или везение?) пришло с очередной новой работой - хотя она не связана с PLD/FPGA, но в моей текущей компании эти направления значительно развиты, есть и знатоки - которые подсказали кое-что по инструментам, по выбору языка - а заодно показали и репозиторий с "домашками" от их собственного курса... Я засучил рукава, добавил компилятор в "песочницу" и вот уже первые несколько заданий ждут энтузиастов :) Также ждём знатоков которые захотят помочь с идеями новых задач и верификацией существующих. Итак, переходим к подробностям...

Меня давно интересовал вопрос, насколько сложно написать собственный загрузчик операционной системы. Я не говорю о простой программе, выводящей «Hello, World!», а о полноценном загрузчике, который передаёт управление от встроенного программного обеспечения компьютера ядру операционной системы. Современные загрузчики представляют собой сложные программы, способные загружать множество операционных систем различными способами, учитывая массу нюансов, связанных с программным и аппаратным обеспечением. Читая их исходный код, легко утонуть в деталях и потерять понимание сути и реализации.

Я решил начать изучение с максимально простого подхода, постепенно усложняя задачи, экспериментируя и получая новые знания. Если мне удалось вас заинтересовать, добро пожаловать под кат.

Привет! Меня зовут Дмитрий Руденко, я из команды Databases Т-Банка. В последние годы наблюдается тенденция к переходу на Postgres со стороны многих команд и компаний, что приводит к увеличению количества Postgres-баз данных, требующих эффективного мониторинга и управления. 

Мы достигли впечатляющего масштаба — почти 10 000 работающих экземпляров PostgreSQL, с которыми работают более 2 000 команд. Каждый из этих инстансов обслуживает уникальные рабочие нагрузки, разработанные командами с различными подходами к архитектуре, используемыми фреймворками и паттернами проектирования.

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

В основе проекта лежит компьютерное зрение и машинное обучение. Система использует веб-камеру для захвата изображения рук пользователя в реальном времени. Затем специально обученная нейронная сеть распознает конкретные жесты и преобразует их в команды управления компьютером. Проект полностью открыт и доступен на GitHub. Установка достаточно простая — нужен только Python 3 и несколько библиотек, которые устанавливаются через pip. Вся настройка сводится к выполнению пары команд в терминале.

Привет, Хабр!

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

Изначально, когда я решил написать компилятор за выходные, я решил, что нет смысла заморачиваться, и использовал сторонний лексический / синтаксический анализатор. Мой выбор пал на SLY, довольно известную библиотеку. И действительно, пара часов работы, и мой компилятор прекрасно строил синтаксические деревья из исходного кода на wend. Я пытался было заглянуть под капот, утонул в море технических терминов (LL(1), LR, LALR(1) и тому подобное), и решил, что парсинг своими руками - это не для меня, теория формальных языков меня слабо интересует. Однако же в итоге выяснилось, что базовый синтаксический анализатор - это не так сложно, и я закатал рукава.

Исторически сложилось так, что автору в течение достаточно длительного периода приходилось разрабатывать мультимедийную поддержку для Windows-приложений. Вначале использовался DirectShow, но в какой-то момент произошло знакомство с проектом FFmpeg, который привлек своей мощью, универсальностью и гибкостью. В процессе работы с FFmpeg было написано немало кода: обертка на C++ для FFmpeg API, а также ряд утилит и GUI решений для .NET. Когда эти результаты достигли определенной степени зрелости, возникло желание поделиться ими с программистским сообществом и заодно изложить свое понимание архитектуры FFmpeg и компьютерного мультимедиа вообще.

Всем привет! Сегодня расскажу про Confluent Kafka. Ее любят, ненавидят, но мало кто остается равнодушным.

О себе

Меня зовут Алена, я ведущий разработчик, занимаюсь развитием референсной архитектуры в компании билайн. К основным областям профессиональных интересов можно отнести проблемы распределенных систем, event sourcing и DDD.

В двух словах о Kafka

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

В первой части мы разобрали как работать с sysdig. А сегодня мы максимально подробно разберем такой базовый инструмент диагностики как top. Несмотря на то, что это базовый инструмент и не такой интересный как тот же sysdig, мы не можем обойти его стороной. По ходу мы приправим все теорией и разберем практический пример анализа вывода.