В помощь разработчику: Vagrant

Давно установил VirtualBox, чтобы на домашней машине под Windows играться с Linux CentOS и исследовать различные настройки, конфигурации и программные пакеты. Но заметил, что много времени уходит на создание виртуалок и установку с нуля очередного образа CentOS, пусть даже и минимального. Захотелось больше гибкости и скорости в создании вируталок и их подготовке к работе.

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

Принципы написания торговых low-latency приложений на Java

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

Статья ориентирована на программистов, чтобы помочь им в изучении Java, понимании JVM и развитии навыков программирования.

Пулы объектов для достижения высокой производительности в Java

В торговых приложениях создается множество объектов в реальном времени. Скажем, каждый новый ордер от клиента создает объект Order. Исполнение ордера на рынке порождает новый объект Fill или Partial Fill. И если поток ордеров очень высок во время активного торгового дня, это создание новых объектов оказывает:

• большую нагрузку на JVM по созданию новых экземпляров объектов из классов;
• большую нагрузку на память, для записи всех этих объектов в heap;
• большую нагрузку на сборщик мусора, который должен постоянно отслеживать появление этих новых объектов и проверять, не стали ли они мусором.

Все эти операции имеют большие накладные расходы сами по себе, плюс могут привести к непредсказуемым задержкам, поэтому Java-программисты нашли обходное решение этой проблемы: использовать пулы заранее созданных объектов (object pools). Т.е. переиспользовать объекты, которые уже не нужны, вместо создания новых.

Размышления о программной инженерии

«Программная инженерия — это приложение инженерных принципов к разработке программного обеспечения». В данной статье хочу выразить пару своих мыслей по поводу software engineering и свое видение этого предмета.

Торговый движок биржи

Торговый движок биржи (matching engine) — это сердце биржи. В нем хранятся все ордера от клиентов и ордера на покупку сводятся с ордерами на продажу.

Почувствовать машину

Термин «Mechanical Sympathy» ввел в обиход программистов разработчик Мартин Томпсон. Взял он его из мемуаров знаменитого шотландского гонщика Джеки Стюарта (Jackie Stewart) 60-ых годов, неизменного победителя всех гонок Formula-1 1965-1973 годов. Когда его спросили, как ему удается побеждать, он ответил:

You don’t have to be an engineer to be a racing driver, but you do have to
have mechanical sympathy.

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

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

Какое отношение это все имеет к программированию?

Нет нужды пересказывать всё, что было уже сказано в многочисленных презентациях Мартина Томпсона, который даже свой блог назвал Mechanical Sympathy. Последние записи в блоге, увы, датированы 2013 годом, но статьи, опубликованные в нем, по-прежнему актуальны и интересны.

Mechanical sympathy упоминается и в книге Optimizing Java, что естественно. Невозможно оптимизировать Java-приложение, не понимая механику JVM, сборщика мусора, операционной системы и так далее.

Данная статья является лишь моим скромным пересказом идеи mechanical sympathy.

habr.com: Числа, которые должен знать каждый программист

Чтобы было понятно, на чём следует концентрироваться при оптимизации, слайд из доклада «Создание программных систем в Google и его уроки»:

Чистый код как культура программирования

Поднятая недавно тема парадокса «разбитых окон» привела к рождению данного поста. Как говорится, «чисто не там, где убирают, а там, где не сорят«. О важности чистого кода написана Робертом Мартином (Uncle Bob) замечательная книга Clean Code, которую я очень рекомендую почитать, а также посмотреть его видео-лекции на тему чистого кода: умно, кратко, понятно, по делу и с юмором.

Ну, а как же сделать так, чтобы команда в коде не сорила? Помимо устного свода правил, обучения новичков, проверки кода, есть некотоые инструменты, которые помогают каждому программисту в команде автоматически следить за качеством своего и чужого кода и замечать на ранних этапах следы «ржавчины», «разбитые окна» и мусор в коде, еще до того, как наросли сверху слои нового мусора и ржавчины. Чем раньше и быстрее вы будете убирать мусор, тем явнее будет виден новый мусор, тем труднее будет в чистом коде сорить вам и другим разработчикам в команде.

О «железе»

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

О разбитых окнах и культуре производства

К теме чистого кода, культуре производства программного обеспечения, навыков работы в команде: заметка Руслана Черемина. И наше с ним обсуждение.