Forwarded from Lilu Maque
#rust #gateway #senior #удаленка
We are looking for a Senior Gateway Engineer for one of the top companies in the field of HFT.
We expect that the candidate will join the Trading Platform Team to work on exchange gateways for a new algorithmic trading platform.
We offer a chance to build complex solutions using cutting edge technologies and mature software engineering practices in the atmosphere of creativity and collaboration.
Responsibilities:
Given high-level business and technical requirements, discuss all the related details with trading/devops teams, design architecture of trading platform gateways for maximum reliability and performance;
Research and reverse-engineer exchange external APIs to find undocumented ways to achieve fastest communication;
Implement proposed solutions using modern technology stack;
Ensure quality, reliability and performance of developed solutions using automated (unit, integration, performance) and manual testing;
Document implemented modules;
Communicate with peer teams on integrations, deployment and support of implemented solutions;
Maintain and improve implemented connectors according to business needs and feedback.
Skills and Experience:
4+ years of relevant work experience;
Strong adherence to principles of effective software engineering - SOLID, TDD;
Understanding of computer systems and software architecture - Linux OS, networks, data structures and algorithms, parallel programming, distributed computing, performance optimization;
Extensive experience with Rust, or familiarity with Rust and experience in strong-typed language eg C++ / C# /Go;
Deep understanding of communication protocols - TCP, UDP, HTTP/REST, WebSocket;
Proven hands-on experience in exchange gateways development;
Self-motivated, with strong analytical and problem solving skills;
Strong communication skills (upper intermediate English);
Degree in Computer Science, a related field or equivalent professional experience.
Bonus Points:
Experience in the HFT or related areas;
Hacking skills are encouraged.
Отклик: @lilumaque
We are looking for a Senior Gateway Engineer for one of the top companies in the field of HFT.
We expect that the candidate will join the Trading Platform Team to work on exchange gateways for a new algorithmic trading platform.
We offer a chance to build complex solutions using cutting edge technologies and mature software engineering practices in the atmosphere of creativity and collaboration.
Responsibilities:
Given high-level business and technical requirements, discuss all the related details with trading/devops teams, design architecture of trading platform gateways for maximum reliability and performance;
Research and reverse-engineer exchange external APIs to find undocumented ways to achieve fastest communication;
Implement proposed solutions using modern technology stack;
Ensure quality, reliability and performance of developed solutions using automated (unit, integration, performance) and manual testing;
Document implemented modules;
Communicate with peer teams on integrations, deployment and support of implemented solutions;
Maintain and improve implemented connectors according to business needs and feedback.
Skills and Experience:
4+ years of relevant work experience;
Strong adherence to principles of effective software engineering - SOLID, TDD;
Understanding of computer systems and software architecture - Linux OS, networks, data structures and algorithms, parallel programming, distributed computing, performance optimization;
Extensive experience with Rust, or familiarity with Rust and experience in strong-typed language eg C++ / C# /Go;
Deep understanding of communication protocols - TCP, UDP, HTTP/REST, WebSocket;
Proven hands-on experience in exchange gateways development;
Self-motivated, with strong analytical and problem solving skills;
Strong communication skills (upper intermediate English);
Degree in Computer Science, a related field or equivalent professional experience.
Bonus Points:
Experience in the HFT or related areas;
Hacking skills are encouraged.
Отклик: @lilumaque
Forwarded from Profunctor Jobs
Backend Senior
Стэк: Java, JavaScript, Go
Денег: $50000-80000
Remote
Fintech startup (Boston)
Founders ex-Revolut, ex-Miro.
Seed round is closed. Series A in progress
Стэк: Java, JavaScript, Go
Денег: $50000-80000
Remote
Fintech startup (Boston)
Founders ex-Revolut, ex-Miro.
Seed round is closed. Series A in progress
Forwarded from Блог*
#prog #article
Почему эта статься называется "Regular-expression derivatives reexamined"? Это не оригинальная статья, а более современный пересказ оригинальной статьи Брзозовски (вот pdf, но читать не советую — это просто довольно грубый скан с бумаги, над нормальной перепечаткой которого никто не заморачивался). Идея производной от регулярного выражения оказалось достаточно плодотворной, чтобы её можно было обобщить до более продвинутых конструкций. Собственно, в этой статье от Мэтта Майта и прочих (pdf) вводится в рассмотрение производная от контекстно-свободных грамматик (CFG), заданных при помощи взаимно-рекурсивных определений, содержащих альтернативы, конкатенацию и звезду Клини, и на основе этого определения реализуется на Racket парсер (именно парсер, а не распознаватель) таких грамматик. Весь код в итоге занял около 30 строк, но для корректной работы полагался на ленивость, мемоизацию и вычисление неподвижных точек функций (есть также реализация на Haskell, но она выглядит так себе, в частности, там зачем-то есть вызов
Как показал себя этот парсер на практике? Паршиво: на разбор 31-строчного синтаксически корректного файла на Python у парсера ушло три минуты. Причина? Неконтролируемые взятия производной от грамматики приводят к тому, что ошмётки грамматики растут экспоненциально. Введение дополнительного шага обработки, названного авторами "сжатием" (compaction) и состоящей в преобразованиях грамматики, уменьшающей её размер, но сохраняющей поведение, привело к желаемому эффекту — повышению производительности. Тем не менее, производительность всё равно осталась достаточно низкой — на разбор того же 31-строчного файла теперь уходило две секунды. Многовато.
Так что же, парсинг с использованием производных (parsing with derivatives, PwD) является непрактичной игрушкой? Отнюдь, как было показано в статье Майкла Адамса. Сложность у этого алгоритма отнюдь не экспоненциальная, как считали авторы, а кубическая. Также оригинальная реализация была написана несколько неоптимально. Во-первых, вычисление неподвижных точек производилось при помощи многократного вызова одной и той же функции, что приводило в худшем случае к квадратичной сложности. Более умная реализация позволяет найти неподвижную точку за линейно время. Во-вторых, в правилах compaction были пропущены парочка правил переписывания грамматики, введение положительно сказалось на производительности. В-третьих, мемоизация в оригинальной реализации использовала хэш-таблицы (причём вложенные). Перемещение мемоизируемых данных из таблиц непосредственно в узлы грамматики положительно сказалось на производительности (надо отметить, что на практике в этих вложенных таблицах было не более одной записи. Хранение единственного значения, разумеется, снизило возможности мемоизации, но, как ни странно, на практике не сильно сказалось на производительности). Итого? Та же идея, но производительность выше на три порядка. Элегантность кода и краткость кода, впрочем, была потеряна.
Можно ли сделать лучше? В принципе, да. Последовательное взятие производной требует многократного прохода по одному и тому же графу, причём, как правило, обход с корня идёт по почти тому же самому пути. Для оптимизации работы над деревьями есть специальная структура данных, zipper (pdf), которая позволяет сфокусироваться на какой-то части дерева и иметь к ней быстрый доступ (кстати, сам автор, Huet, не считает себя изобретателем этой структуры данных, поскольку она переизобреталась неоднократно, статью же он написал главным образом ради того, чтобы идея была более известна). Встраивание зиппера в PwD позволяет повысить его производительность.
Почему эта статься называется "Regular-expression derivatives reexamined"? Это не оригинальная статья, а более современный пересказ оригинальной статьи Брзозовски (вот pdf, но читать не советую — это просто довольно грубый скан с бумаги, над нормальной перепечаткой которого никто не заморачивался). Идея производной от регулярного выражения оказалось достаточно плодотворной, чтобы её можно было обобщить до более продвинутых конструкций. Собственно, в этой статье от Мэтта Майта и прочих (pdf) вводится в рассмотрение производная от контекстно-свободных грамматик (CFG), заданных при помощи взаимно-рекурсивных определений, содержащих альтернативы, конкатенацию и звезду Клини, и на основе этого определения реализуется на Racket парсер (именно парсер, а не распознаватель) таких грамматик. Весь код в итоге занял около 30 строк, но для корректной работы полагался на ленивость, мемоизацию и вычисление неподвижных точек функций (есть также реализация на Haskell, но она выглядит так себе, в частности, там зачем-то есть вызов
unsafePerformIO).Как показал себя этот парсер на практике? Паршиво: на разбор 31-строчного синтаксически корректного файла на Python у парсера ушло три минуты. Причина? Неконтролируемые взятия производной от грамматики приводят к тому, что ошмётки грамматики растут экспоненциально. Введение дополнительного шага обработки, названного авторами "сжатием" (compaction) и состоящей в преобразованиях грамматики, уменьшающей её размер, но сохраняющей поведение, привело к желаемому эффекту — повышению производительности. Тем не менее, производительность всё равно осталась достаточно низкой — на разбор того же 31-строчного файла теперь уходило две секунды. Многовато.
Так что же, парсинг с использованием производных (parsing with derivatives, PwD) является непрактичной игрушкой? Отнюдь, как было показано в статье Майкла Адамса. Сложность у этого алгоритма отнюдь не экспоненциальная, как считали авторы, а кубическая. Также оригинальная реализация была написана несколько неоптимально. Во-первых, вычисление неподвижных точек производилось при помощи многократного вызова одной и той же функции, что приводило в худшем случае к квадратичной сложности. Более умная реализация позволяет найти неподвижную точку за линейно время. Во-вторых, в правилах compaction были пропущены парочка правил переписывания грамматики, введение положительно сказалось на производительности. В-третьих, мемоизация в оригинальной реализации использовала хэш-таблицы (причём вложенные). Перемещение мемоизируемых данных из таблиц непосредственно в узлы грамматики положительно сказалось на производительности (надо отметить, что на практике в этих вложенных таблицах было не более одной записи. Хранение единственного значения, разумеется, снизило возможности мемоизации, но, как ни странно, на практике не сильно сказалось на производительности). Итого? Та же идея, но производительность выше на три порядка. Элегантность кода и краткость кода, впрочем, была потеряна.
Можно ли сделать лучше? В принципе, да. Последовательное взятие производной требует многократного прохода по одному и тому же графу, причём, как правило, обход с корня идёт по почти тому же самому пути. Для оптимизации работы над деревьями есть специальная структура данных, zipper (pdf), которая позволяет сфокусироваться на какой-то части дерева и иметь к ней быстрый доступ (кстати, сам автор, Huet, не считает себя изобретателем этой структуры данных, поскольку она переизобреталась неоднократно, статью же он написал главным образом ради того, чтобы идея была более известна). Встраивание зиппера в PwD позволяет повысить его производительность.
Forwarded from Блог*
Первый статья (pdf) (июнь 2020!), с подходом, адаптировавшим зипперы к PwD, использует понятия синтаксиса (как единого объекта) и сфокусированного синтаксиса, который суть синтаксис плюс стек слоёв, который можно к нему применить (отчасти напоминает то, о чём говорил я). Ограничив себя LL(1)-грамматиками, авторы сумели реализовать парсер, работающий за время, пропорциональное количеству входных лексем, причём все важные свойства промежуточных операций они верифицировали при помощи доказательств на Coq. Сам парсер доступен в виде библиотеки на Scala.
Вторая статья (август 2020!) не ограничивается LL(1)-грамматиками, а даёт способ парсить произвольные контекстно-свободные грамматики. Т. к. на вход подаётся лишь единственное правило, поэтому алгоритму приходится разбираться с произвольными графами с циклами и использовать несколько изощрённое обобщение зиппера. Статья ценна тем, что в ней реализация выводится через ряд промежуточных версий (одним из шагов, как и в статье Майкла Адамса, является замена таблицы мемоизаций на единственное значение для мемоизации). Получившийся парсер короче оригинального PwD и при этом показывает лучшую производительность, чем оптимизированный PwD Майкла Адамса. К сожалению, не смотря на то, что данный парсер, по всей видимости, имеет кубическуб производительность для худшего случая, доказать этот факт авторы не сумели из-за приличного количества нетривиальной логики с мемоизацией.
Как вам уже известно, я выкладываю лишь то, что прочитал/посмотрел сам. Последние две статьи я прочитал, но, к сожалению, не уяснил полностью излагаемые там алгоритмы. Буду перечитывать.
Вторая статья (август 2020!) не ограничивается LL(1)-грамматиками, а даёт способ парсить произвольные контекстно-свободные грамматики. Т. к. на вход подаётся лишь единственное правило, поэтому алгоритму приходится разбираться с произвольными графами с циклами и использовать несколько изощрённое обобщение зиппера. Статья ценна тем, что в ней реализация выводится через ряд промежуточных версий (одним из шагов, как и в статье Майкла Адамса, является замена таблицы мемоизаций на единственное значение для мемоизации). Получившийся парсер короче оригинального PwD и при этом показывает лучшую производительность, чем оптимизированный PwD Майкла Адамса. К сожалению, не смотря на то, что данный парсер, по всей видимости, имеет кубическуб производительность для худшего случая, доказать этот факт авторы не сумели из-за приличного количества нетривиальной логики с мемоизацией.
Как вам уже известно, я выкладываю лишь то, что прочитал/посмотрел сам. Последние две статьи я прочитал, но, к сожалению, не уяснил полностью излагаемые там алгоритмы. Буду перечитывать.
Telegram
Блог*
#prog #rust #моё
Исторически решение задач с бектрекингом является более простым в функциональных ЯП с персистентными структурами данных. Взял состояние, немного поменял его и получил новую версию, делаешь на ней рекурсивный вызов, если решение зашло в тупик…
Исторически решение задач с бектрекингом является более простым в функциональных ЯП с персистентными структурами данных. Взял состояние, немного поменял его и получил новую версию, делаешь на ней рекурсивный вызов, если решение зашло в тупик…
Forwarded from Denis Otkydach
Building a runtime reflection system for Rust 🦀️ (Part 1)
https://www.osohq.com/post/rust-reflection-pt-1
https://www.osohq.com/post/rust-reflection-pt-1
Osohq
Build a runtime reflection system for Rust Pt. 1 – oso
Part 1 of our series on building a runtime reflection system in Rust.
Forwarded from Igor Gulamov
#вакансия #rust #senior #remote #удаленно #fulltime #halftime #blockchain
Формат работы: #удаленка
Занятость: #полная #частичная
Оплата: $25-50/h
О проекте: международный проект, который делает полностью анонимные транзакции, с возможностью переводов внутри продукта. Проект основан ресерчерами, но уже сейчас виден большой потенциальный спрос на будущий продукт.
О соискателе: ты готов работать удаленно, имеешь опыт работы на rust и substrate, тебе не нужно объяснять, как работает подпись на эллиптических кривых и меркл дерево.
Основная задача - разработка смарт контрактов и модулей на substrate.
Проект активно привлекает гранты от мировых лидеров индустрии, быстро растет, появляются новые задачи и возможности для профессионального роста.
Подробности в PM.
Формат работы: #удаленка
Занятость: #полная #частичная
Оплата: $25-50/h
О проекте: международный проект, который делает полностью анонимные транзакции, с возможностью переводов внутри продукта. Проект основан ресерчерами, но уже сейчас виден большой потенциальный спрос на будущий продукт.
О соискателе: ты готов работать удаленно, имеешь опыт работы на rust и substrate, тебе не нужно объяснять, как работает подпись на эллиптических кривых и меркл дерево.
Основная задача - разработка смарт контрактов и модулей на substrate.
Проект активно привлекает гранты от мировых лидеров индустрии, быстро растет, появляются новые задачи и возможности для профессионального роста.
Подробности в PM.
Forwarded from Kai Ren
Настоятельно рекомендую ознакомиться, либо освежить в памяти, если уже читали, это:
https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md
https://github.com/pretzelhammer/rust-blog/blob/master/posts/common-rust-lifetime-misconceptions.md
GitHub
rust-blog/posts/common-rust-lifetime-misconceptions.md at master · pretzelhammer/rust-blog
Educational blog posts for Rust beginners. Contribute to pretzelhammer/rust-blog development by creating an account on GitHub.
Forwarded from Технологический Болт Генона
Интересный цикл постов от автора визитки с linux на борту
Mastering Embedded Linux, Part 1: Concepts
https://www.thirtythreeforty.net/posts/2019/08/mastering-embedded-linux-part-1-concepts/
Mastering Embedded Linux, Part 2: Hardware
https://www.thirtythreeforty.net/posts/2019/12/mastering-embedded-linux-part-2-hardware/
Mastering Embedded Linux, Part 3: Buildroot
https://www.thirtythreeforty.net/posts/2020/01/mastering-embedded-linux-part-3-buildroot/
Mastering Embedded Linux, Part 4: Adding Features
https://www.thirtythreeforty.net/posts/2020/03/mastering-embedded-linux-part-4-adding-features/
Mastering Embedded Linux, Part 5: Platform Daemons
https://www.thirtythreeforty.net/posts/2020/05/mastering-embedded-linux-part-5-platform-daemons/
Mastering Embedded Linux, Part 1: Concepts
https://www.thirtythreeforty.net/posts/2019/08/mastering-embedded-linux-part-1-concepts/
Mastering Embedded Linux, Part 2: Hardware
https://www.thirtythreeforty.net/posts/2019/12/mastering-embedded-linux-part-2-hardware/
Mastering Embedded Linux, Part 3: Buildroot
https://www.thirtythreeforty.net/posts/2020/01/mastering-embedded-linux-part-3-buildroot/
Mastering Embedded Linux, Part 4: Adding Features
https://www.thirtythreeforty.net/posts/2020/03/mastering-embedded-linux-part-4-adding-features/
Mastering Embedded Linux, Part 5: Platform Daemons
https://www.thirtythreeforty.net/posts/2020/05/mastering-embedded-linux-part-5-platform-daemons/
www.thirtythreeforty.net
Mastering Embedded Linux, Part 1: Concepts
A high-level introduction to concepts in hacking cheap embedded Linux systems
Forwarded from Блог*
Forwarded from Darya
наши вопросы на собеседовании растовиков
# Раст
* c++ и rust: отличия в строении vtable
* зачем нужны ZST?
* как safe раст гарантирует отсутствие data race?
* что такое object safety
# Структуры данных
* btree
* hashmap (+ linkedhashmap)
* bloom filter (+ cuckoo filter)
# Растовое окружение
* как дела с сериализацией/десериализацией, какие форматы
* ошибки: операциональные/программерские, когда использовать assert, когда Error. failure
* асинхронщина: tokio, futures
* как устроен eventloop, как он связан с поллингом
# Общие вопросы
* чем low latency отличается от high throughput?
* sync/async? block/nonblock?
* linux планироващик
* cpu/numa affinity
* гипертрединг
* TCP vs UDP
* способы организации IPC в linux
* потоки vs корутины, когда что использовать
# Раст
* c++ и rust: отличия в строении vtable
* зачем нужны ZST?
* как safe раст гарантирует отсутствие data race?
* что такое object safety
# Структуры данных
* btree
* hashmap (+ linkedhashmap)
* bloom filter (+ cuckoo filter)
# Растовое окружение
* как дела с сериализацией/десериализацией, какие форматы
* ошибки: операциональные/программерские, когда использовать assert, когда Error. failure
* асинхронщина: tokio, futures
* как устроен eventloop, как он связан с поллингом
# Общие вопросы
* чем low latency отличается от high throughput?
* sync/async? block/nonblock?
* linux планироващик
* cpu/numa affinity
* гипертрединг
* TCP vs UDP
* способы организации IPC в linux
* потоки vs корутины, когда что использовать
Таненбаум "Архитектура компьютера"
Скиена "Алгоритмы"
Клеппман "Высоконагруженные приложения"
Эспозито "Архитектура корп. приложений"
Скиена "Алгоритмы"
Клеппман "Высоконагруженные приложения"
Эспозито "Архитектура корп. приложений"
Forwarded from kamyshev.code
Современный бэкенд для фронтенда на Node.js
Вчера посмотрел доклад про BFF на летнем HolyJS и очень кайфанул — классный обзор бекендов для фронтендов, решаемых задачи и возникающих проблем. Очень хотел им поделиться, но (почему-то) был уверен, что в паблик его еще не выложили. А оказалось, что выложили.
#фронтенд #проектирование
Вчера посмотрел доклад про BFF на летнем HolyJS и очень кайфанул — классный обзор бекендов для фронтендов, решаемых задачи и возникающих проблем. Очень хотел им поделиться, но (почему-то) был уверен, что в паблик его еще не выложили. А оказалось, что выложили.
#фронтенд #проектирование