Фотография: Stephane YAICH (Unsplash.com)

В серии из нескольких материалов для блога ITinvest мы обсудили ход развития технологий и IT-инфраструктуры для биржевых торгов и рынка алгоритмического трейдинга. Взлет последнего повлек за собой экспоненциальный рост объемов как обрабатываемых в моменте, так и исторических данных по финансовым операциям. Сегодня эти данные, их полнота и возможность представления в нужном формате — «воздух» для тех, кто обучает и тестирует свои торговые алгоритмы и модели.

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

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

Ранее мы познакомились с языком Smalltalk, а точнее с его микро реализацией Little Smalltalk. Разобрались с синтаксисом языка, форматом представления объектов в памяти и набором основных инструкций. Теперь мы вплотную подошли к вопросам взаимодействия Smalltalk и LLVM (ради этого и затевалась вся серия статей).

Сейчас у нас есть вся необходимая база знаний для того чтобы понять, что именно делается в нашем JIT компиляторе. В этой статье мы узнаем, как байт-коды Smalltalk преобразуются в IR код LLVM, как происходит компиляция и выполнение кода, и почему это работает быстрее, чем программная интерпретация. Самые нетерпеливые могут посмотреть шеллкасты (раз и два) с циферками и бегущими строчками (не забывайте про возможность скроллинга).

Всем привет! Совместно с humbug, мы предлагаем вашему вниманию третью статью из цикла о Low Level Smalltalk (LLST). Надемся, что статья будет интересна не только любителям велосипедов необычных языков программирования, но и тем, кто интересуется такой замечательной вещью, как LLVM.

Напомню, что целью нашего проекта является создание собственной виртуальной машины, совместимой с Little Smalltalk на уровне байт-кодов. Ключевым отличием является гетерогенная архитектура, которая позволяет исполнять байт-коды как программно, так и компилировать их в низкоуровневые инструкции процессора посредством трансляции в IR код LLVM. Разумеется, второй способ позволяет достичь более высокой производительности и задействовать имеющиеся в нашем распоряжении вычислительные ресурсы оптимальным образом.

Однако, обо всем по порядку…

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

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

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

Биржевые и околобиржевые компании создают серьезный спрос на программистов, занятых совершенно разными вещами — от автоматизации бэкофиса до дата майнинга. Очень серьезные зарплаты и ответственность имеют разработчики так называемых High Frequency Trading algorithms, высокочастотных торговых алгоритмов. Написать этот пост меня сподвиг один занудный и одновременно забавный фильм (youtube, 50 минут, без перевода), в котором разработчик Хаим Бодек очень просто объясняет суть происходящего в HFT.

Поток заявок на покупку-продажу в биржевом "стакане" Бодек ассоциирует с очередью за редким товаром, которого не хватает

Фотография: Taylor Vick (Unsplash.com)

Это продолжение нашего обсуждения развития технологической зависимости HFT-трейдеров. Вновь говорим о том, какие факторы вступили в игру, когда Wall Street дала ход различным телеком- и ИТ-решениям из высокотехнологичной отрасли. Обращаем внимание на замечания в расследовании журналистов по этой теме и делимся некоторыми дополнениями дискуссии.

Не так давно мы съездили к нейрофизиологу Михаилу Бурцеву, заведующему лаборатории нейроинтеллекта и нейроморфных систем в Курчатовском Институте. Он рассказал нам, чем его сотрудники занимаются, что такое нейрональные культуры и для чего вообще-то нужно изучать мозг.

Пройдемся по новинкам и покодируем по-новому.

Итак, начнем по списку.

Допустим, имеется список.

List<Integer> numbers = Arrays.asList(1, 2, 3, 4, 5, 6);

Теперь вспомним, как мы итерировали в старые времена:

for (int i = 0; i < numbers.size(); i++){
 System.out.println(numbers.get(i));
}

Все здорово, но уж очень легко оступиться и поставить <= вместо < или начать с 1 вместо 0. В вышеприведенном коде мы полностью контролируем механику, мы держим в голове все движущие части. Это хорошо во многих случаях, и никто у нас этого не отобрал в Java 5, только добавили сахарку.

Давным давно в одной из компаний, лидере мирового производства микропроцессоров, меня однажды поразила менеджерская напасть. Решил, знаете ли, заняться развитием сотрудников. (Периодически, такое с менеджерами случается, да.)

Подхожу к своему сотруднику — назовем его Серега:

— Серега, — говорю, — ты в какую сторону вообще хочешь развиваться: в техническую или в менеджерскую?

— Сань, ну голова варит уже не очень, возраст… (Серега старше меня на 3 года) Поэтому, наверное, в менеджерскую.

Ну, в менеджерскую — так в менеджерскую. Я ж на тот момент был менеджер опытный, уже 4 года опыта! Энергии много, желания помочь людям — через край!

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

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

Заодно поговорим, что делать, если вы обнаружили себя и/или своих сотрудников в квадрате C в статье:

• Управленческие инструменты: Как играть в нелинейные шахматы

Добрый день, уважаемые коллеги. Данная статья будет являться продолжением темы, начатой в посте habrahabr.ru/post/178103.
Продолжим с того момента, когда у нас уже есть значения конструктивных постоянных для двигателя Lego, и можно перейти к конструированию и обсчету робота. В качестве опытного образца остановимся на Segway. Это одна из наиболее показательных задач теории автоматического управления. Привожу конструкцию этого механизма.

К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.

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

Не так давно на Хабре была статья «Коды Грея и задачи перебора». Статья эта скорее, математическая, нежели программистская, и мне, как простому программисту, читать её было невыносимо тяжело. Но сама тема мне знакома, поэтому я решил описать её своим взглядом, а так же рассказать о том, как использовал её в решении задачи о ранце.


КДПВ: задача о ранце на живом примере

Предыстория

Всё началось 10 лет назад, когда я учился в девятом классе. Я случайно подслушал разговор учителя по информатике, рассказывающего задачку кому-то из старших: дан набор чисел, и ещё одно число — контрольное. Надо найти максимальную сумму чисел из набора, которая не превышала бы контрольное число.

Задача почему-то запала мне в душу. Вернувшись домой, я быстро накатал решение: наивный перебор всех возможных сумм с выбором наилучшего. Сочетания я получал, перебирая все N-разрядные двоичные числа и беря суммы тех исходных чисел, которым соответствуют единицы. Но я с огорчением обнаружил, что при количестве элементов начиная где-то с 30, программа работает очень долго. Оно и не удивительно, ведь время работы такого алгоритма — n*2ⁿ (количество сочетаний, умноженное на длину суммы).

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

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

• необходимость A/B-тестирования разных версий одной и той же игры
• возможность по максимуму переиспользовать функциональность от одной игры в другой
• высокую вероятность географической удаленности от разработчиков занимающихся клиентской частью игры

Более того, в дальнейшем нашу команду предполагалось расширить, возможно за счет аутсорс разработчиков, в том числе и для задач поддержки. В этих условиях для успешной реализации было решено наравне с версионированием проектов, пакетированием и стандартизацией ряда шагов разработки внедрить и практику continuous delivery.

Цель данной статьи – рассказать о проделанных шагах, принятых решениях и описать полученный результат.

Второго октября в Монреале прошло очередное мероприятие Google Tech Talks.

Более 150 человек пришло с единственной целью — послушать доклад Алекса Ионеску, который известен российской аудитории, в первую очередь, как соавтор книг серии Windows Internals.

Доклад Алекса назывался "The Crazy Open Source Attempt To Rewrite Windows From Scratch" и целиком посвящен операционной системе ReactOS. Выступление насыщено интересными подробностями и содержит в себе практически исчерпывающий отчет об истории создания и современном состоянии проекта ReactOS.


Рекомендуется сразу переключить плеер в разрешение 480р и развернуть на полный экран.
Скачать в максимальном качестве с английскими субтитрами (335 МБ).
magnet:?xt=urn:btih:D74DDE9C8CAD16AB1782DB7B071D8A977A74E0E5

Яндексу ежедневно приходится отвечать на десятки миллионов запросов. Поисковая система должна уметь быстро и точно их обрабатывать. Без применения лингвистики поисковая система сможет найти только точные совпадения в проиндексированных документах. Чтобы найти релевантные документы, системе необходимо правильно определить язык запроса, исправить опечатки, произвести морфологический разбор каждого слова, расширить запрос синонимами или вообще его переформулировать. В этой лекции Алексей Зобнин постарался дать студентам Малого ШАДа ответы на следующие вопросы:

• Зачем нужно учитывать морфологию?
• Как и зачем мы определяем язык запроса и документа?
• Что такое корпус языка?
• Что такое языковые модели, и как они применяются в поиске?
• Как производится морфологический анализ несловарных слов?
• Как определить правильное значение и морфологическую парадигму омонимов?
• Какие бывают опечатки, и как мы их исправляем?
• Что такое расширения запроса и чем они могут быть полезны?

Страница лекции

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

В ходе прочтения этой статьи и комментариев к ней, у меня сформировалось стойкое ощущение, что большинство пользователей, использующих другие дистрибутивы, имеют не совсем верное представление о gentoo-like системах. Скорее всего виновато в этом само словосочетание «source-based».

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

Чем крупнее и сложнее становится сервис, тем больше времени приходится уделять тестированию. Поэтому желание автоматизировать и формализовать этот процесс вполне законно.

Чаще всего для автоматизации тестирования веб-сервисов применяется Selenium WebDriver. Как правило, с его помощью пишут функциональные тесты. Но, как всем хорошо известно, функциональные тесты не могут решить задачу тестирования верстки сервиса, что требует проведения дополнительных ручных, зачастую кроссбраузерных, проверок. Как тест может оценить корректность верстки? Чтобы обнаружить регрессионные ошибки верстки, тесту потребуется некоторый эталон, в качестве которого может выступать изображение корректной верстки, взятой, например, с продакшен-версии сервиса. Этот подход носит название screenshot-based testing. Подход этот применяется достаточно редко, и чаще всего верстку все же тестируют вручную. Причина этому – ряд достаточно строгих требований к сервису, к среде выполнения тестов и к самим тестам.

Расширенные ответы сервисов Яндекса в результатах поиска — мы у себя внутри по старой традиции называем их «колдунщиками» — дополнительное звено, в котором что-то может сломаться.

На примере тестирования колдунщиков в поиске мы расскажем, какими особенностями должен обладать тестируемый сервис, какие проблемы возникают у нас при использовании screenshot-based testing, и как мы их решаем.

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

1. иметь малые накладные расходы по памяти. Большая часть доступной памяти должна использоваться для хранения текста, а не служебной информации;
2. допускать эффективную вставку и удаление в произвольном месте текста.

Удовлетворить эти требования одновременно непросто. Если рассмотреть широкоизвестные структуры данных, такие как массивы, списки, деревья, стеки, очереди, кольцевые буфера — то такой структуры, которая бы позволила эффективно выполнить оба требования, не встречается. В случае массива имеем незначительные накладные расходы по памяти, но операция вставки имеет сложность O(n), где n — размер редактируемого текста. В случае списка сложность вставки и удаления составляет O(1), однако накладные расходы по памяти в несколько раз превышают размер собственно текста. Деревья, кучи, кольцевые буфера, ассоциативные массивы и прочие структуры и вовсе неприменимы для хранения текста в редакторе.

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

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

Несмотря на то, что эта структура данных была открыта давно и использовалась в текстовых редакторах на старых ЭВМ в 8-битную эпоху, это тайное знание предков было в значительной мере утеряно и в современных редакторах встречается редко. Попробуйте открыть файл, состоящий из одной строки мегабайт на 10, в Notepad или Far. Вставка и удаление символов будет длиться секундами.