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

[Первая часть]

Снижение объема фондовых рынков может до определенной степени быть связано с тем, что высокочастотный трейдинг отпугивает инвесторов от вложений в ценные бумаги, что особенно заметно после события 6 мая 2010 года, получившего название Flash Crash, когда принятое компьютерами решение о продаже большого количества фьючерсов вызвало массовый обвал цен на рынке. Промышленный индекс Dow Jones упал на 600 пунктов примерно за 5 минут. Когда произошел скачок цен, большинство высокочастотных трейдеров, работавших на рынке в тот день, обогатились. А тех, чьи машины в тот день не работали, обвинили в пособничестве обвалу и недообеспечении ликвидности, поскольку падение ускорилось из-за того, что сравнительно немногие высокоскоростные трейдеры были готовы купить акции, снижение цен на которые все нарастало под давлением тех, кто хотел их продать.

Компания Stamen из Сан-Франциско объединилась с Nasdaq для визуализации бешеного ритма автоматизированных торгов. Рисунок иллюстрирует запросы на покупку и продажу, отправленные алгоритмами в течение всего лишь одной минуты (на иллюстрации изображены торги от 8 марта 2011г.)

Стив Свенсон (Steve Swanson) был типичным 21-летним компьютерным гиком с очень нетипичной работой. Дело было летом 1989 года, и он только что получил степень математика в Колледже Чарльстона. В одежде его привлекали футболки и шлепанцы, а на телевидении – сериал Звездный Путь. Большую часть времени он проводил в гараже Джима Хоукса (Jim Hawkes), преподавателя статистики из колледжа, в котором учился Стив. Там он программировал алгоритмы для того, что в последствии станет первой в мире компанией, ведущей высокочастотную торговлю, и получит название Automated Trading Desk. Хоукса преследовала навязчивая идея о том, что можно получать прибыль на фондовых рынках, используя формулы для предсказания поведения цен, выведенные его другом, Дэвидом Уиткомбом (David Whitcomb), преподававшим экономику в Ратгерском Университете. Задачей Свенсона было превратить формулы Уиткомба в машинный код.

Инструменты, которые мы будем использовать

Docker

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

Собрав контейнер один раз, его можно многократно использовать.

Простой пример — это БД Redis. Если нам необходимо несколько серверов Redis на одном компьютере, при обычном подходе нам придется изменять конфигурационные файлы в /etc/redis и менять файлы в /etc/init.d. Можно написать bash скрипт, но это не делает процесс легче.

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

^{Изображение: Kevin Ku — Unsplash}

На Хабре часто появляются материалы о том, как IT-специалисту сохранить и приумножить свои деньги. Неудивительно, что тема вызывает интерес и все больше дискуссий. На днях мне попалась статья парня, который, применив свои технологические навыки, смог за год заработать полмиллиона долларов. Мне кажется, его опыт может быть интересен многим (даже если отбросить тот факт, что он не первый день на бирже), поэтому я предлагаю обсудить его мысли. Но сделать это в два подхода — оригинальный пост достаточно объемный для одного хабратопика.

^{Изображение: Chris Liverani — Unsplash}

Это продолжение разбора темы (часть 1), захватившей мое внимание и пришедшейся по душе на Хабре. Обсуждаем проект парня, который, применив свой опыт в IT, смог заработать полмиллиона долларов.

Наблюдая за своими родителями-пенсионерами, а точнее за размерами их пенсий, я крепко задумываюсь о том, как обеспечить себе нечто оное в достойном меня размере. На государство в составе СНГ рассчитывать, похоже, не приходится. Значит, надо что-то делать самому! И начинать надо сейчас, пока мне 32 года, есть какой-никакой заработок и силы крутиться. Раньше были мысли, что я буду вечно молодым, вечно здоровым и все время что-то делать. Постепенно начинаю осознавать, что лет 20… 30 — и силы будут таять (или распыляться). Поэтому пару лет назад я начал понемногу что-то делать в этом направлении. Получил некоторый опыт, который может быть интересен уважаемому сообществу. Даже если для читателя вопрос пенсии сейчас звучит безумно абстрактно, то все равно рекомендую хотя бы пробежаться. Если бы я 5 лет назад почитал такой материал — я был бы уже существенно богаче!..
UPD: в статье добавил про смысл диверсификации, а то в комментариях много вопросов было…

Перевод небольшой заметки Yakov Fain с сайта javalobby.org о том, как обилие фреймворков на любой вкус лишают разработчиков необходимости знать, как всё устроено «под капотом». Думаю, эта проблема не ограничивается только Java, а всё ещё актуальна для любого языка, не смотря на то, что статья достаточно старая.

От переводчика: Это перевод первой статьи из цикла «Networking for game programmers». Мне очень нравится весь цикл статей, плюс всегда хотелось попробовать себя в качестве переводчика. Возможно, опытным разработчикам статья покажется слишком очевидной, но, как мне кажется, польза от нее в любом случае будет.

---

Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.


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

Вы, скорее всего, уже что-нибудь слышали о сокетах, и, возможно, знаете, что они делятся на два основных типа — TCP и UDP. Первое, что нужно решить при разработке многопользовательской игры — это какой тип сокетов использовать — TCP, UDP, или оба?

^{Длинный материал. Время чтения – около 40 минут.}



Доктор Ричард Хэмминг, профессор морской школы Монтерея в штате Калифорния и отставной учёный Bell Labs, прочёл 7 марта 1986 года очень интересную и стимулирующую лекцию «Вы и ваши исследования» переполненной аудитории примерно из 200 сотрудников и гостей Bellcore на семинаре в серии коллоквиумов в Bell Communications Research. Эта лекция описывает наблюдения Хэмминга в части вопроса «Почему так мало учёных делают значительный вклад в науку и так многие оказываются в долгосрочной перспективе забыты?». В течение своей более чем сорокалетней карьеры, тридцать лет которой прошли в Bell Laboratories, он сделал ряд прямых наблюдений, задавал учёным очень острые вопросы о том, что, как, откуда, почему они делали и что они делали, изучал жизни великих учёных и великие достижения, и вёл интроспекцию и изучал теории креативности. Эта лекция о том, что он узнал о свойствах отдельных учёных, их способностях, чертах, привычках работы, мироощущении и философии.

От переводчика: это перевод статьи Кристиана Глобмайера The Ten Rules of a Zen Programmer. Статья мне понравилась, решил сделать перевод, после окончания перевода загуглил название, нашел вариант перевода: 10 принципов дзен программиста. Отличается от моего, поэтому решил свой вариант перевода все-таки запостить.

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

Одним дождливым утром я сидел за своим столом и думал об эффективной работе. До того, как я начал работать фрилансером, у меня бывало, что я работал много, но никогда не был доволен результатом. Я начал практиковать Дзен в 2006 году. То, что мне пришло в голову через довольно большое время — старые мастера Дзен уже знали сотни лет назад, как сегодняшние программисты должны работать. Хотя я не люблю посты «как быть лучшим программистом», я хочу рассказать о некоторых моих мыслях с того времени. Этот пост будет служить мне напоминанием, но если у вас есть идеи, не стесняйтесь оставлять комментарии.

В этой статье я расскажу о начале своей работы над совершенно безбашенной задачей: конечная цель в том, чтобы получить рабочую микросхему по «толстым» нормам (5-10µm) дома. Это не первое апреля и я не сумасшедший, это просто моё хобби.

Возникла эта идея не сейчас и неспроста. С детства я хотел быть газосварщиком, и… делать микросхемы. И если по первому пункту мне достаточно быстро удалось сделать дома сварочный аппарат (бутан-водород/кислород), то с микросхемами все никак не складывалось. Долгое время все мысли останавливались на том, что я не знал где можно взять собственно полупроводники необходимой чистоты (и мысли останавливались на ковырянии мощных транзисторов), пока на форуме не подсказали что в принципе, можно и купить пластины. Затем я даже наткнулся на человека, который 20 лет работал над похожей задачей, и в итоге сдался. Пожалуй, тут можно было опустить руки и перестать тратить время на глупые мечты. Но, однажды я увидел ролик чудовищно гениальной женщины – Jeri Ellsworth – она смогла сделать отдельные полевые транзисторы на основе заводских пластин – и тогда я решил, что настало время поплотнее заняться этой проблемой.

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

Приветствую, хабр!

Напишу о том, как мне довелось поучаствовать и победить в ежегодном чемпионате по программированию искусственного интеллекта Russian AI Cup 2013 (codetroopers). Выступал я там под ником slash и занял первое место как в финале, так и в песочнице на момент подведения в ней итогов.

Открытые вакансии на должность разработчика в Яндексе есть всегда. Компания развивается, и хороших программистов не хватает постоянно. И претендентов на эти должности тоже хоть отбавляй. Главная сложность – отобрать действительно подходящих кандидатов. И в этом плане Яндекс мало чем отличается от большинства крупных IT-компаний. Так что базовые принципы, описываемые в этой статье, могут быть применимы не только к Яндексу.

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

Введение

Сегодня я продолжу рассказ о применении методов анализа данных и машинного обучения на практических примерах. В прошлой статье мы с вами разбирались с задачей кредитного скоринга. Ниже я попытаюсь продемонстрировать решение другой задачи с того же турнира, а именно «Задачи о паспортах» (Задание №2).
При решении будут показаны основы анализа текстовой информации, а также ее кодирование для построения модели с помощью Python и модулей для анализа данных (pandas, scikit-learn, pymorphy).

Компания SearchMetrics, разрабатывающая аналитические программы для SEO, ежегодно исследует тысячи сайтов на первых страницах SERP по разным запросам, чтобы выявить закономерности попадания различных ресурсов в выдачи поисковых систем. А далее – определить важность тех или иных факторов при ранжировании этих площадок в Google. В 2013 году сайты, выпадающие на топовых страницах SERP, объединяют сильные социальные сигналы. Среди приблизительно 50 анализируемых факторов на первом месте по важности оказалось число +1 на Google+. Далее в списке идут: количество шеров на Facebook, количество и качество обратных ссылок (заметьте, только третье место), число друзей, лайков, комментариев на Facebook, активность на Pinterest и Twitter и т. д.

В предыдущей статье мы заглянули внутрь процессора, пусть и гипотетического. Мы выяснили, что для корректного выполнения параллельного кода процессору необходимо подсказывать, до каких пределов ему разрешено проводить свои внутренние оптимизации чтения/записи. Эти подсказки – барьеры памяти. Барьеры памяти позволяют в той или иной мере упорядочить обращения к памяти (точнее, кэшу, — процессор взаимодействует с внешним миром только через кэш). “Тяжесть” такого упорядочения может быть разной, — каждая архитектура может предоставлять целый набор барьеров “на выбор”. Используя те или иные барьеры памяти, мы можем построить разные модели памяти — набор гарантий, которые будут выполняться для наших программ.

В этой статье мы рассмотрим модель памяти C++11.

В этой статье я даю краткий обзор того, как применять библиотеку lock-free структур данных libcds. В реализацию я углубляться здесь не буду, — это просто взгляд извне, взгляд со стороны пользователя библиотеки.

Библиотека libcds имеет свою точку зрения на многие известные структуры данных. Отчасти это объясняется целевой областью – lock-free структуры данных довольно минималистичны по набору предоставляемых методов, — отчасти желанием выйти за ограничения и решения стандартной библиотеки STL. Что из этого получилось – решать пользователям libcds.

Кому интересно – добро пожаловать под кат

Как только я заинтересовался lock-free алгоритмами, меня стал мучить вопрос – а откуда взялась необходимость в барьерах памяти, в «наведении порядка» в коде?
Конечно, прочитав несколько тысяч страниц руководств по конкретной архитектуре, мы найдем ответ. Но этот ответ будет годен для этой конкретной архитектуры. Есть ли общий? В конце концов, мы же хотим, чтобы наш код был портабелен. Да и модель памяти C++11 не заточена под конкретный процессор.
Наиболее приемлемый общий ответ дал мне мистер Paul McKenney в своей статье 2010 года Memory Barriers: a Hardware View of Software Hackers. Ценность его статьи – в общности: он построил некоторую упрощенную абстрактную архитектуру, на примере которой и разбирает, что такое барьер памяти и зачем он был введен.
Вообще, Paul McKenney – известная личность. Он является разработчиком и активным пропагандистом технологии RCU, которая активно используется в ядре Linux, а также реализована в последней версии libcds в качестве ещё одного подхода к безопасному освобождению памяти (вообще, о RCU я хотел бы рассказать отдельно). Также принимал участие в работе над моделью памяти C++11.
Статья большая, я даю перевод только первой половины. Я позволил себе добавить некоторые комментарии, [которые выделены в тексте так].