Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 25.11.07 23:09
Оценка:
Господа,

— Вы программируете на Эрланге?

— Имеете понимание оного и какой-то опыт?

— Вам интересны нетривиальные проекты на Эрланге?

Свяжитетсь со мной, пожалуйста, по почте. Контактная информация на http://wagerlabs.com

На данный момент у меня на подходе больше проектов на Эрланге, чем я могу осилить, да и собственно программирование мне уже не так интересно, как аспекты системного дизайна, маркетинга, продаж и т.д. Так же, у меня есть продукт (OpenPoker), который нужно активно развивать и поддерживать. Я хочу собрать толковую команду, т.к. целина Эрланга весьма перспективна и пахать ее кому-то надо.

Спасибо, Joel

P.S. Мой C.V. http://wagerlabs.com/resume.pdf
P.P.S. Писать прошу, по возможности, по-английски.
--
http://wagerlabs.com
Re: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 26.11.07 15:38
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

афигеть! кстати, я думаю, что ему можно предложить и на хаскеле что-то сделать. он сам порбовал на нём поработать, но у него как-то не сложились с ним отноешения
Люди, я люблю вас! Будьте бдительны!!!
Re[2]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 26.11.07 15:52
Оценка:
BZ>афигеть! кстати, я думаю, что ему можно предложить и на хаскеле что-то сделать. он сам порбовал на нём поработать, но у него как-то не сложились с ним отноешения

Нет, на Хаскеле мне предлагать ничего не надо. У меня нет пока на него коммерческого спроса.
--
http://wagerlabs.com
Re[2]: Ищу программирующих на Эрланге
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.11.07 16:37
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>афигеть! кстати, я думаю, что ему можно предложить и на хаскеле что-то сделать. он сам порбовал на нём поработать, но у него как-то не сложились с ним отноешения


Сразу вылезает цитата SPJ отсюда:

Since "inevitability" is a hard sell for Haskell right now, avoid mentioning ML or Erlang. There needs to be only one FPL for a manager, or he will fret about VHS vs. Betamax syndrome (and he won't want to have been the one to invest in a Betamax).

Re[3]: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 26.11.07 17:29
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

BZ>>афигеть! кстати, я думаю, что ему можно предложить и на хаскеле что-то сделать. он сам порбовал на нём поработать, но у него как-то не сложились с ним отноешения


JR>Нет, на Хаскеле мне предлагать ничего не надо. У меня нет пока на него коммерческого спроса.


афигеть совсем!!! откуда такое знание русского языка? я думал — кто-то тебе перевёл объявление

и раз так — как может быть коммерческий спрос на язык?? я так понимаю — ты сам его считаешь плохим вариантом

Курилке: я бы не назвал Джоэля менеджером. год назад он пытался написать клиент к этому самому покер-серверу на хаскеле (только начав его изучение — это никого тебе не напоминает? ). в конце концов, после двух месяцев, когда всё cafe ему помогало в этом процессе — там сотни тредов, десериализация, реал-тайм — он плюнул и за неделю переписал его на эрланге. на мой взгляд, проблема была именно в том, что Джоэль сразу взялся за нетривиальную задачу, упёрся в скорость библиотеки десериализации и не захотел её заменить другой, а на эрланге быстро переписал потому, что алгоритм уже был обсуждён, оставалось только записать его на похожем языке. во всяком случае, она от этого переписывания быстрее не стала. ну а сам Джоэль сделал вывод, что хаскель — плохой язык
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: Ищу программирующих на Эрланге
От: Курилка Россия http://kirya.narod.ru/
Дата: 26.11.07 17:34
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>Здравствуйте, Joel Reymont, Вы писали:


BZ>афигеть совсем!!! откуда такое знание русского языка? я думал — кто-то тебе перевёл объявление


Hint: биографи у Джоэля довольно оригинальная, хотя это вроде гуглом как минимум запросто ищется

BZ>Курилке: я бы не назвал Джоэля менеджером. год назад он пытался написать клиент к этому самому покер-серверу на хаскеле (только начав его изучение — это никого тебе не напоминает? ). в конце концов, после двух месяцев, когда всё cafe ему помогало в этом процессе — там сотни тредов, десериализация, реал-тайм — он плюнул и за неделю переписал его на эрланге. на мой взгляд, проблема была именно в том, что Джоэль сразу взялся за нетривиальную задачу, упёрся в скорость библиотеки десериализации и не захотел её заменить другой, а на эрланге быстро переписал потому, что алгоритм уже был обсуждён, оставалось только записать его на похожем языке. во всяком случае, она от этого переписывания быстрее не стала. ну а сам Джоэль сделал вывод, что хаскель — плохой язык


Дак, Булат, яж это лишь как "мысль по поводу", а по erlang questions и не только про Джоэля я уже чуток знал...
Re[3]: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 26.11.07 17:58
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

BZ>>афигеть! кстати, я думаю, что ему можно предложить и на хаскеле что-то сделать. он сам порбовал на нём поработать, но у него как-то не сложились с ним отноешения


JR>Нет, на Хаскеле мне предлагать ничего не надо. У меня нет пока на него коммерческого спроса.


на твоём сайте написано, чт тебе нужен только программтст для развития покер-сервера. понятно, что хаскелу там не место
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 26.11.07 18:16
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:

BZ>и раз так — как может быть коммерческий спрос на язык??


Очень просто: ко мне не стучатся клиенты с просьбами написать им что-нибудь на Хаскеле, но стучатся и просят Эрланг!

BZ>я так понимаю — ты сам его считаешь плохим вариантом


Хаскел отличный язык, но я пока не знаю для чего. Проще пишется и быстрее работает написанное на OCaml. Проще пишется и куда круче масштабируется написанное на Эрланге. Если бы я писал что-нибудь с критериями безопасности, как например galois.com (криптологические системы для правительства США), то я обязательно бы выбрал Хаскел.

BZ>Курилке: я бы не назвал Джоэля менеджером. год назад он пытался написать клиент к этому самому покер-серверу на хаскеле


Осмелюсь скорректировать вышенаписанное... Писал я софт для тестирования чужого покер-сервера, что-то типа scalable test harness. Требовалось дать возможность клиенту эмулировать несколько тысяч игроков, что пользуются покер сервером, т.е. играют, по лобби лазают и проч. На Хаскеле я боролся с диким использованием памяти, сериализацией и т.д. Перейдя на Эрланг я быстро выяснил, что проблема не в Хаскеле и не в Эрланге.

Алгоритмов особых не было, задача тривиальная. Клепать пакеты для покер сервера, отсылать, получать и далее по кругу. Идеальная задача для Эрланга, но мне хотелось изучить Хаскел. Сам клиент предпочел в итоге "DSL" на Эрланге тому же на Хаскеле.

Не так давно я написал транслятор с трейдингового языка EasyLanguage в C#. Сначала я написал его на Хаскеле, но меня достало преобразовывать структуры из одного формата в другой в монадах. Я переписал транслятор на OCaml (который решил изучить) и использовать polymorphic variants мне понравилось куда больше. Кстати, мне так же нужен программист на F# чтобы этот транслятор переписать под Виндоуз.
--
http://wagerlabs.com
Re[4]: Ищу программирующих на Эрланге
От: Mamut Швеция http://dmitriid.com
Дата: 27.11.07 08:12
Оценка:
BZ>афигеть совсем!!! откуда такое знание русского языка? я думал — кто-то тебе перевёл объявление

Все описано здесь:
http://groups.google.com/group/hardcore_erlang/t/601c237a9f04603e


dmitriid.comGitHubLinkedIn
Re[5]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 27.11.07 14:00
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Не так давно я написал транслятор с трейдингового языка EasyLanguage в C#. Сначала я написал его на Хаскеле, но меня достало преобразовывать структуры из одного формата в другой в монадах. Я переписал транслятор на OCaml (который решил изучить) и использовать polymorphic variants мне понравилось куда больше. Кстати, мне так же нужен программист на F# чтобы этот транслятор переписать под Виндоуз.


Занятно. А почему С# — это требование заказчика? Для трейдинговых нужд, скажем, для торговых роботов, и для нужд движка скриптинга куда лучше подходит Java. Там гранулярность загрузки — класс, и неиспользуемый код подбирается GC автоматически. В отличии от .NET. Во вторых — для Java есть почти рилтаймовые сборщики мусора, скажем, в WebLogic RealTime Edition. Я бы не отважился делать торговых роботов на C# — самый паршивый выбор.

Как кстати твои проекты по поводу применения Эрланга в финансовой индустрии (всякие там stocks quotes and exchanges)? Несколько лет назад ты писал об этом в мэйллист.
Re[6]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 27.11.07 14:20
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Занятно. А почему С# — это требование заказчика? Для трейдинговых нужд, скажем, для торговых роботов, и для нужд движка скриптинга куда лучше подходит Java. Там гранулярность загрузки — класс, и неиспользуемый код подбирается GC автоматически.


Большая часть трейдинговых продуктов для простых смертных написана на .NET (NinjaTrader, RightEdge, OpenQuant).

G>Как кстати твои проекты по поводу применения Эрланга в финансовой индустрии (всякие там stocks quotes and exchanges)? Несколько лет назад ты писал об этом в мэйллист.


Никак пока. Сейчас, вот, пишу книжку по Эрлангу (Harcore Erlang) для Pragmatic Programmers, собираюсь там показать как можно stock exchange написать на Эрланге. С другой стороны, один из клиентов хочет portfolio management and analysis platform. Я сначала предложил Эрланг, а потом оказалось что у них портфели огромного размера и аналитика должна прогоняться максимально быстро. Пришлось предложить OCaml и масштабирование с помощью Ensemble.
--
http://wagerlabs.com
Re[7]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 27.11.07 14:27
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Здравствуйте, Gaperton, Вы писали:


G>>Занятно. А почему С# — это требование заказчика? Для трейдинговых нужд, скажем, для торговых роботов, и для нужд движка скриптинга куда лучше подходит Java. Там гранулярность загрузки — класс, и неиспользуемый код подбирается GC автоматически.


JR>Большая часть трейдинговых продуктов для простых смертных написана на .NET (NinjaTrader, RightEdge, OpenQuant).


Понятно.

G>>Как кстати твои проекты по поводу применения Эрланга в финансовой индустрии (всякие там stocks quotes and exchanges)? Несколько лет назад ты писал об этом в мэйллист.


JR>Никак пока. Сейчас, вот, пишу книжку по Эрлангу (Harcore Erlang) для Pragmatic Programmers, собираюсь там показать как можно stock exchange написать на Эрланге. С другой стороны, один из клиентов хочет portfolio management and analysis platform. Я сначала предложил Эрланг, а потом оказалось что у них портфели огромного размера и аналитика должна прогоняться максимально быстро. Пришлось предложить OCaml и масштабирование с помощью Ensemble.


Огромный размер портфеля — это сколько?

Мне кажется, можно и с Эрлангом. Аналитику подцеплять драйвером, и писать на чем угодно, неважно, а Эрланг обеспечивает масштабируемость и отказоустойчивость.
Re: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 27.11.07 14:30
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Господа,


JR>- Вы программируете на Эрланге?


JR>- Имеете понимание оного и какой-то опыт?


JR>- Вам интересны нетривиальные проекты на Эрланге?


JR>Свяжитетсь со мной, пожалуйста, по почте. Контактная информация на http://wagerlabs.com


JR>На данный момент у меня на подходе больше проектов на Эрланге, чем я могу осилить, да и собственно программирование мне уже не так интересно, как аспекты системного дизайна, маркетинга, продаж и т.д. Так же, у меня есть продукт (OpenPoker), который нужно активно развивать и поддерживать. Я хочу собрать толковую команду, т.к. целина Эрланга весьма перспективна и пахать ее кому-то надо.


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

Вопросы:
1) Ты делаешь фокус на продуктовой разработке, или на заказной? Каковы твои планы на эту тему в перспективе 2-3 года?
2) Ты готов давать субподряды, или хочешь работать индивидуально с разработчиками?
3) Насколько стабилен у тебя поток заказов, и в каких предметных областях?
Re[8]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 27.11.07 15:06
Оценка:
G>Огромный размер портфеля — это сколько?

Не могу сказать, NDA подписал.

G>Мне кажется, можно и с Эрлангом. Аналитику подцеплять драйвером, и писать на чем угодно, неважно, а Эрланг обеспечивает масштабируемость и отказоустойчивость.


Можно и драйвером подцеплять, хотя клиент желает аналитику менять без перекомпиляции всей системы.

На самом деле, я не вижу почему данную систему обязательно писать на Эрланге, знаю успешные примеры применения OCaml в этой области (смотри здесь)и просто хочу попробовать.

Масштабируемость и отказоустойчивость это само собой, но что насчет работы с time series размером в миллионы элементов? Как представлять в Эрланге эти самые time series? Как tuples, binaries? Как проходить по ним функционально (map, fold)? То что математика в Эрланге страдает это давно известно, а двигать прогресс на примере этого проекта я не готов. В книжке описать это другое дело, мне на нее куда больше времени дадено.
--
http://wagerlabs.com
Re[2]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 27.11.07 15:24
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Команду собрать без проблем. Как вариант — я могу взять от тебя субподряд и собрать команду эрлангистов. Одного программера готов выделить очень быстро — он есть в наличии. Если будет выгодно — надо обсудить детали лично, я могу собрать достаточно большую группу.


Влад, ты знаешь куда писать. Пиши!

G>Вопросы:

G>1) Ты делаешь фокус на продуктовой разработке, или на заказной? Каковы твои планы на эту тему в перспективе 2-3 года?

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

Так же у меня есть пара относительно перспективных, но недоделанных продуктов (OpenPoker, Topdog), и желание сконцентрироваться на продажах, маркетинге и выявлении новых ниш на рынке.

Почему я сам не доведу продукты до ума? Лень мешает и программировать надоело. Скоро 20 лет как я научился и 16 лет как я получаю за это деньги.

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

G>2) Ты готов давать субподряды, или хочешь работать индивидуально с разработчиками?


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

Я бы предпочел собрать собственную группу, но меня можно переубедить.

G>3) Насколько стабилен у тебя поток заказов, и в каких предметных областях?


Потом заказов пока нестабилен. Предметные области разные, от трейдинга и иже с ним, до веб программирования. В принципе, я программирую на чем придется (Lisp, Erlang, OCaml, Haskell), но полагаю что фокус все таки будет на Эрланге.
--
http://wagerlabs.com
Re[3]: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 27.11.07 15:54
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Я бы предпочел собрать собственную группу, но меня можно переубедить.


на мой скромный взгляд вам больше подходит равноправное партнёрство. за тобой — контакты с западным миром (заказчиками, pr). за гапертоном — работа с исполнителями, техническая часть, архитектура, менеджмент
Люди, я люблю вас! Будьте бдительны!!!
Re[4]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 27.11.07 16:05
Оценка: :)))
BZ>на мой скромный взгляд вам больше подходит равноправное партнёрство. за тобой — контакты с западным миром (заказчиками, pr). за гапертоном — работа с исполнителями, техническая часть, архитектура, менеджмент

Почему нет? Gaperton, добавь меня в Facebook, пожалуйста, или напиши напрямую.

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

--
http://wagerlabs.com
--
http://wagerlabs.com
Re[3]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 27.11.07 16:50
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

G>>Команду собрать без проблем. Как вариант — я могу взять от тебя субподряд и собрать команду эрлангистов. Одного программера готов выделить очень быстро — он есть в наличии. Если будет выгодно — надо обсудить детали лично, я могу собрать достаточно большую группу.


JR>Влад, ты знаешь куда писать. Пиши!

Ок, детали обсудим почтой. Уже пишу.

G>>Вопросы:

G>>1) Ты делаешь фокус на продуктовой разработке, или на заказной? Каковы твои планы на эту тему в перспективе 2-3 года?

JR>На данный момент у меня есть некая популярность, которая транслируется в заказчиков с проектами. По мере того, как книжка будет приближаться к концу, популярность и количество проектов будет рости. Люди понимают перспективность Эрланга, но программистов все равно не хватает.


Ок. Грамотно и правильно. У меня, к сожалению, не хватает терпения не то что на книгу, но даже на статьи.

JR>Так же у меня есть пара относительно перспективных, но недоделанных продуктов (OpenPoker, Topdog), и желание сконцентрироваться на продажах, маркетинге и выявлении новых ниш на рынке.


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

JR>Почему я сам не доведу продукты до ума? Лень мешает и программировать надоело. Скоро 20 лет как я научился и 16 лет как я получаю за это деньги.


Я так полагаю, также потому, что текучка малосовместима с разработкой стратегии, делать это одновременно очень тяжело почему-то. У меня по крайней мере так — лень тут не причем. .

JR>Хотелось бы иметь линейку продуктов, но начинать надо все равно с заказного программирования. Я пока не миллионер и финансировать разработку новых продуктов из собственного кармана не могу, следовательно остается финансирование с контрактов.


Разумеется, по другому никак. Я думаю, у тебя есть наметки в плане возможных продуктовых ниш на будущее. Скажем, пример со stock exchange в книгу ты не просто так включаешь . Но это однозначно лучше почтой обсуждать.

G>>2) Ты готов давать субподряды, или хочешь работать индивидуально с разработчиками?


JR>У меня есть некий опыт в этой области. В свое время я занимался оффшорным программированием из Штатов, набирая команды по России и бывшим республикам. Опыт настолько отрицательный, что я вернулся в Питер и собрал собственную команду. Качество работы было всегда на высоте, я ведь сам подбирал команды с опытом и менеджментом. Проблема в том, что слишком высок стимул для команд работать с заказчиком в обход меня.


Мне кажется, это можно решить, имея относительно небольшую команду у тебя, которая выполняла бы работы по общей архитектуре и работе с требованиями (формулировка ТЗ в технических терминах), планирование, выдачу заданий и контроль выполнения, а также приемку работ и их интеграцию. То есть, надо иметь локально SCM, QA, и архитекторов с менеджерами.
Re[4]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 27.11.07 17:09
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Мне кажется, это можно решить, имея относительно небольшую команду у тебя, которая выполняла бы работы по общей архитектуре и работе с требованиями (формулировка ТЗ в технических терминах), планирование, выдачу заданий и контроль выполнения, а также приемку работ и их интеграцию. То есть, надо иметь локально SCM, QA, и архитекторов с менеджерами.


На Канары переехать не желаешь?
--
http://wagerlabs.com
Re[5]: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 27.11.07 17:13
Оценка: :)
Здравствуйте, Joel Reymont, Вы писали:

JR>Здравствуйте, Gaperton, Вы писали:


JR>На Канары переехать не желаешь?


а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца
Люди, я люблю вас! Будьте бдительны!!!
Re[6]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 27.11.07 17:27
Оценка: :)
BZ>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца

Со смогом тут очень плохо.

Солнце, море. Температура в течении года колеблется в районе +21C, хотя летом куда жарче.

Как пить дать загнется!
--
http://wagerlabs.com
Re[7]: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 27.11.07 19:00
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Со смогом тут очень плохо.


JR>Солнце, море. Температура в течении года колеблется в районе +21C, хотя летом куда жарче.


JR>Как пить дать загнется!


придётся ему в портивогазе ходить!
Люди, я люблю вас! Будьте бдительны!!!
Re[9]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.07 10:00
Оценка:
короче, портфель не может быть совсем огромным. столько контрактов в мире нет Сильно сомневаюсь что размер портфеля превысит 10000 инструментов, и уверен, что на самом деле их в районе 1000.

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

G>>Мне кажется, можно и с Эрлангом. Аналитику подцеплять драйвером, и писать на чем угодно, неважно, а Эрланг обеспечивает масштабируемость и отказоустойчивость.


JR>Можно и драйвером подцеплять, хотя клиент желает аналитику менять без перекомпиляции всей системы.


Не проблема подцеплять аналитику через Dll. А если хватит производительности, то можно завернуть ее в С-Node.

JR>На самом деле, я не вижу почему данную систему обязательно писать на Эрланге, знаю успешные примеры применения OCaml в этой области (смотри здесь)и просто хочу попробовать.


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

JR>Масштабируемость и отказоустойчивость это само собой, но что насчет работы с time series размером в миллионы элементов?


Торговые роботы не работают с такими длинными сериями. Они реагируют на отдельные котировки. Прогонять их на истории (Backtesting) — решается записью и прогоном фида.

В остальном — миллионы котировок делятся на торговые сессии, и стратегии четко делятся на Intraday и Historical. То есть, с миллионным временным рядом как единым целым тебе иметь дело не придется.

>Как представлять в Эрланге эти самые time series? Как tuples, binaries?


Есть масса вариантов. Один список рекордов на сессию. Или последовательность сообщений. Короче, с этим принципиальных проблем нет.

>Как проходить по ним функционально (map, fold)?


Сделать свой аналог Foldl, Который может работать на самой кривой структуре, на самом деле.

С теми же самыми проблемами ты столкнешься и в окамле, кстати. Никуда они не денутся. И решатся будут примерно так жк.

>То что математика в Эрланге страдает это давно известно, а двигать прогресс на примере этого проекта я не готов.


Математику можно как раз подцеплять внешнюю, делая ее на окамле или с++.
Re[10]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 28.11.07 11:56
Оценка: +1
Зачем изобретать велосипед, если есть специализированные продукты? Тот же kdb+, где и язык к тому же функциональный. Правда, лицензия стоит денег.
Re[11]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 28.11.07 12:19
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Зачем изобретать велосипед, если есть специализированные продукты? Тот же kdb+, где и язык к тому же функциональный. Правда, лицензия стоит денег.


Она не просто стоит денег, она стоит БОЛЬШИХ денег. Скажем, $40К за процессор, с минимальной покупкой в 4. Плюс, я пробовал попросить у них пробник, но мне не дали. Показали пальцем на конкурирующий продукт, который я собирался изобрести .
--
http://wagerlabs.com
Re[11]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 28.11.07 12:24
Оценка:
Я забыл ответить на вопрос... Если я изобрету этот велосипед за год, то овчинка уже будет стоить выделки.

По запросам желающих, у меня складывается впечатление что программисты в регионах и бывших республиках получают по $3.5К и больше в месяц. Даже если выдавать желаемое за действительное, то все равно можно собрать команду из нескольких человек и написать что-нибудь подобное. Кстати, рекомендую посмотреть на MonetDB.
--
http://wagerlabs.com
Re[12]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 28.11.07 12:53
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Она не просто стоит денег, она стоит БОЛЬШИХ денег. Скажем, $40К за процессор, с минимальной покупкой в 4. Плюс, я пробовал попросить у них пробник, но мне не дали. Показали пальцем на конкурирующий продукт, который я собирался изобрести .


Да, дорого. Думал, что за 40 все-таки можно взять. Но она того стоит.
MonetDB отличается в некоторых местах в нелучшую сторону — хоть и column based, но порядок записей все равно не фиксирован и поддерживается только SQL. Язык в kdb+, я считаю, является главным ее преимуществом в полном соответствии с известной статьей Грехема. Пока конкуренты поддерживают только SQL или неуклюжие довески типа PL-SQL, акционерам kx бояться нечего.
Re[13]: Ищу программирующих на Эрланге
От: Курилка Россия http://kirya.narod.ru/
Дата: 28.11.07 12:58
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>MonetDB отличается в некоторых местах в нелучшую сторону — хоть и column based, но порядок записей все равно не фиксирован и поддерживается только SQL. Язык в kdb+, я считаю, является главным ее преимуществом в полном соответствии с известной статьей Грехема. Пока конкуренты поддерживают только SQL или неуклюжие довески типа PL-SQL, акционерам kx бояться нечего.


А можно пояснить, что под выделенным имелось в виду?
Re[14]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 28.11.07 13:11
Оценка:
Здравствуйте, Курилка, Вы писали:

К>А можно пояснить, что под выделенным имелось в виду?


У Пола Грехема есть статья, где он рассуждает на тему ЯП. Там он утверждает, что Лисп был главным конкурентным преимуществом их компании, что они не сильно волновались, когда появлялись конкуренты, заявлявшие, что они используют что-то типа С++. Q в kdb обладает похожими свойствами, пока конкуренты прикручивают что-то через (O|J)DBC к обычной БД, ты пишешь тоже самое за 5-ть минут на Q.
Re[13]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 28.11.07 13:12
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>MonetDB отличается в некоторых местах в нелучшую сторону — хоть и column based, но порядок записей все равно не фиксирован и поддерживается только SQL.


А что значит порядок записей не фиксирован? Можно подробнее?
--
http://wagerlabs.com
Re[12]: Ищу программирующих на Эрланге
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.11.07 13:44
Оценка:
Здравствуйте, Joel Reymont

Прошу прощения, что вмешиваюсь в ваш разговор, но вот не совсем понял:

JR>По запросам желающих, у меня складывается впечатление что программисты в регионах и бывших республиках получают по $3.5К и больше в месяц.


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


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 28.11.07 13:46
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>А что значит порядок записей не фиксирован? Можно подробнее?


Я имел в виду то, что там (как во всех обычных БД) порядок записей в БД не специфицирован, т.е. ты не знаешь заранее, как именно физически новая запись будет расположена относительно уже существующих. Это не очень удобно, когда заранее известно, что у данных есть естественный порядок (для финансовых данных — это время). В kdb+ порядок записей всегда известен и меняется детерминировано, это позволяет производить над данными вычисления, недоступные в обычной БД (вычислять n-й элемент, сравнивать соседние по порядку элементы и т.п.).

Вот недавно, как раз, интересовались этим:

---------

А>Выбрать все акции цена на которые в один день поднялась на 10 пунктов

А>на второй день опустилась на 15 пунктов
А>а на третий день поднялась на 30 пунктов
А>можно ли такие запросы эффективно делать ?

Если есть предвычисленная база всех статистических параметров типа priceData = (date; stock; open; close; hi; low; vwap; ... ), то элементарно:

Через временную таблицу:
select stock from (select flag: (10 -15 30)~close-open by stock from priceData where date in (d-til 3)) where flag
или одним запросом:
select distinct stock from priceData where date in (d-til 3), (~[10 -15 30]; close-open) fby stock

---------

За счет того, что priceData упорядочена по времени, запросы получаются элементарными и работают очень быстро.
Re[15]: Ищу программирующих на Эрланге
От: Курилка Россия http://kirya.narod.ru/
Дата: 28.11.07 13:47
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Курилка, Вы писали:


К>>А можно пояснить, что под выделенным имелось в виду?


Q>У Пола Грехема есть статья, где он рассуждает на тему ЯП. Там он утверждает, что Лисп был главным конкурентным преимуществом их компании, что они не сильно волновались, когда появлялись конкуренты, заявлявшие, что они используют что-то типа С++. Q в kdb обладает похожими свойствами, пока конкуренты прикручивают что-то через (O|J)DBC к обычной БД, ты пишешь тоже самое за 5-ть минут на Q.


Наверное эта. Да, согласен, есть такой факт, получается что-то типа legacy не только в коде, а и в сознании
Re[13]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 28.11.07 13:52
Оценка:
Здравствуйте, eao197, Вы писали:

E>Т.е. вы получили несколько резюме от соискателей, который проживают в регионах и которые просят от $3.5 и выше за эту работу?


Люди хотят получать $20 в час. Я их не виню.
--
http://wagerlabs.com
Re[14]: Ищу программирующих на Эрланге
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.11.07 13:55
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Здравствуйте, eao197, Вы писали:


E>>Т.е. вы получили несколько резюме от соискателей, который проживают в регионах и которые просят от $3.5 и выше за эту работу?


JR>Люди хотят получать $20 в час. Я их не виню.


Молодцы, однако! Зря что ли сидя в провинции они Erlang учили?


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[11]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.07 13:57
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Зачем изобретать велосипед, если есть специализированные продукты? Тот же kdb+, где и язык к тому же функциональный. Правда, лицензия стоит денег.


Это сложно понять наверно, но это делают затем, чтобы заработать денег. При внешней похожести продукты могут (и будут) сильно отличаться позиционированием — порой играют довольно тонкие различия. У любого продукта также есть сильные и слабые стороны, на которых можно и нужно сыграть. Маркетинг найдет слабые стороны в продуктах конкурентов, и обязательно повернет их себе на пользу, сместив позиционирование (делается это кстати не сложно — есть технология). Наличие конкурентов не только не остановит другие компании от вхождения в рынок, но и является фактором, снижающим риски. Если у тебя конкурентов нет, то
1) это означает отсутствие сформировавшегося рынка, и очень затруднительно достоверно оценить его объем. А это означает, что любая разработка с большими вложениями чрезвычайно рискована. Рынок может быть элемеентарно не готов к твоему решению, если ты опередишь потребности рынка на пару лет — ты пролетишь. Выходить с продуктом надо вовремя. Ты должен очень хорошо представлять себе сбытовую часть в этом случае.
2) Также, отсутствие конкурентов и аналогов афигенно затрудняет анализ требований. Тебе в разы сложнее оценить тенденции пользователей и их потребности.

Функциональность языка программирования как раз на потребительских ТТХ не сказывается. Почему такая штука, написанная на Эрланге, может иметь преимущество перед остальными существующими решениями, я естественно объяснять не буду. Это элемент технологической стратегии, которую на форумах не обсуждают. Достаточно того, что я сам это понимаю.
Re[12]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.07 14:10
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>По запросам желающих, у меня складывается впечатление что программисты в регионах и бывших республиках получают по $3.5К и больше в месяц. Даже если выдавать желаемое за действительное, то все равно можно собрать команду из нескольких человек и написать что-нибудь подобное. Кстати, рекомендую посмотреть на MonetDB.


Цена целовекомесяца в нашем воронежском офисе (зарплата плюс все косвенные издержки офиса пропорционально) примерно 1500 K USD. Она достаточно типична для Воронежа. Зарплата 30К RUR для Воронежа считается очень хорошей. Воронеж — город с миллионом человек населения.

Средняя зарплата вменяемого инженера по москве — 2000-3000 USD чистыми, небольшой процент получает до 4К, выше — это сказки HR. То есть, 3500 в месяц — это нормально для очень хорошего инженера, по меркам москвы.

Зарплаты в Питере всегда были раза в полтора меньше, чем в Москве. Делай выводы.

Насчет outsourcing rates. Luxoft (Москва) продает час примерно по 32$ — это верхняя планка. Нормальное колебание рейта для России — 25-35 долларов. Компания, которая оказывает услуги, будет иметь нормальные характеристики если они в фонд зарплаты отдают совокупно чистыми (после всех налогов) не более трети выручки. Более половины выручки она отдавать ваще не может — концы с концами не сойдутся. Считай среднюю зарплату аутсорсеров.
Re[15]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.07 14:12
Оценка: +1
Здравствуйте, eao197, Вы писали:

JR>>Люди хотят получать $20 в час. Я их не виню.


E>Молодцы, однако! Зря что ли сидя в провинции они Erlang учили?


Эрлангу можно научить даже осла, причем в короткий срок — это не С++. Деньги платят за мозги в голове.

Кстати, уверен на 98%, что Эрланга по настоящему большинство из них не знают — то есть систему крупную они грамотно спроектировать для него не смогут.
Re[16]: Ищу программирующих на Эрланге
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 28.11.07 14:18
Оценка:
Здравствуйте, Gaperton, Вы писали:

JR>>>Люди хотят получать $20 в час. Я их не виню.


E>>Молодцы, однако! Зря что ли сидя в провинции они Erlang учили?


G>Эрлангу можно научить даже осла, причем в короткий срок — это не С++. Деньги платят за мозги в голове.


Если кто-нибудь в провинции самостоятельно взял да и выучил Erlang для себя (а здесь, в одной из провинций нифига за Erlang не платят), то это с очень большой долей вероятности говорит о наличии мозгов в голове.

G>Кстати, уверен на 98%, что Эрланга по настоящему большинство из них не знают — то есть систему крупную они грамотно спроектировать для него не смогут.


Это уже их проблемы.
И боюсь, что не все отлично разбирающиеся в Erlang-е программисты смогут грамотно спроектировать крупную систему. Имхо, знание языка и умение проектировать -- вещи, как минимум ортогональные. А иногда и взаимоисключающие


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[14]: Ищу программирующих на Эрланге
От: Трурль  
Дата: 28.11.07 15:01
Оценка: :)
Здравствуйте, Joel Reymont, Вы писали:

JR>Люди хотят получать $20 в час. Я их не виню.


Винить, конечно, нельзя. Но платить — . На яхту не останется.
Re[15]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 28.11.07 15:08
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, Joel Reymont, Вы писали:


JR>>Люди хотят получать $20 в час. Я их не виню.


Т>Винить, конечно, нельзя. Но платить — . На яхту не останется.


Совершенно верно.

Плачу я за успешно выполненные проекты, а часовую ставку использую чисто для собственной информации.
--
http://wagerlabs.com
Re[15]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 28.11.07 15:10
Оценка:
Здравствуйте, Трурль, Вы писали:

Т>Здравствуйте, Joel Reymont, Вы писали:


JR>>Люди хотят получать $20 в час. Я их не виню.


Т>Винить, конечно, нельзя. Но платить — . На яхту не останется.


Ну, платить-то можно, это будет даже выгодно. Это нижняя граница коммерческого аутсорсинг-рейта для России. Однако, за эти деньги аутсорсится проект целиком, со всей головной болью. Для удаленного исполнителя, который работает по четким ТЗ и маленьким задачам — это многовато.
Re[5]: Ищу программирующих на Эрланге
От: Трурль  
Дата: 28.11.07 15:14
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Хаскел отличный язык, но я пока не знаю для чего.

Для PhD theses.
Re[6]: Ищу программирующих на Эрланге
От: BulatZiganshin  
Дата: 28.11.07 16:40
Оценка:
Здравствуйте, Трурль, Вы писали:

JR>>Хаскел отличный язык, но я пока не знаю для чего.

Т>Для PhD theses.

ага. Джоэль заинтересовался хаскелом прочтя "composing financial contracts". но он жестоко просчитался
Люди, я люблю вас! Будьте бдительны!!!
Re[16]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 29.11.07 09:26
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ну, платить-то можно, это будет даже выгодно. Это нижняя граница коммерческого аутсорсинг-рейта для России. Однако, за эти деньги аутсорсится проект целиком, со всей головной болью. Для удаленного исполнителя, который работает по четким ТЗ и маленьким задачам — это многовато.


Не хотите — не надо, за вычетом налогов, бенефитов и с учетом нестабильности и экзотичности работы, это даже мало.
Re[12]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 29.11.07 09:42
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Это сложно понять наверно, но это делают затем, чтобы заработать денег. При внешней похожести продукты могут (и будут) сильно отличаться позиционированием — порой играют довольно тонкие различия. У любого продукта также есть сильные и слабые стороны, на которых можно и нужно сыграть. Маркетинг найдет слабые стороны в продуктах конкурентов, и обязательно повернет их себе на пользу, сместив позиционирование (делается это кстати не сложно — есть технология). Наличие конкурентов не только не остановит другие компании от вхождения в рынок, но и является фактором, снижающим риски.


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

Если у тебя конкурентов нет, то
G>1) это означает отсутствие сформировавшегося рынка, и очень затруднительно достоверно оценить его объем. А это означает, что любая разработка с большими вложениями чрезвычайно рискована. Рынок может быть элемеентарно не готов к твоему решению, если ты опередишь потребности рынка на пару лет — ты пролетишь. Выходить с продуктом надо вовремя. Ты должен очень хорошо представлять себе сбытовую часть в этом случае.
G>2) Также, отсутствие конкурентов и аналогов афигенно затрудняет анализ требований. Тебе в разы сложнее оценить тенденции пользователей и их потребности.

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

G>Функциональность языка программирования как раз на потребительских ТТХ не сказывается. Почему такая штука, написанная на Эрланге, может иметь преимущество перед остальными существующими решениями, я естественно объяснять не буду. Это элемент технологической стратегии, которую на форумах не обсуждают. Достаточно того, что я сам это понимаю.


Какая штука? Риал-тайм база данных + средства аналитики? Не вижу в этой области у Эрланга никаких преимуществ, тот же ОКамл подошел бы не хуже.
Re[13]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 29.11.07 10:20
Оценка: 1 (1)
Здравствуйте, Quintanar, Вы писали:

G>>Это сложно понять наверно, но это делают затем, чтобы заработать денег. При внешней похожести продукты могут (и будут) сильно отличаться позиционированием — порой играют довольно тонкие различия. У любого продукта также есть сильные и слабые стороны, на которых можно и нужно сыграть. Маркетинг найдет слабые стороны в продуктах конкурентов, и обязательно повернет их себе на пользу, сместив позиционирование (делается это кстати не сложно — есть технология). Наличие конкурентов не только не остановит другие компании от вхождения в рынок, но и является фактором, снижающим риски.


Q>Все это очень мило, но речь идет о заказе одного клиента, а не о самостоятельном продукте.


Речь, разумеется, идет о создании типового решения, т.е. продукта. На заказной разработке маленькая компания заработать денег не может. Бизнес не масштабируемый. Однако, у маленькой компании нет денег на стратегические инвестиции, поэтому она использует деньги по заказной разработке для создания типовых решений. Это — почти единственная выигрышная стратегия.

Q>И с тезисом о конкурентах не могу согласиться, сейчас эту нишу пытаются занять довольно много компаний, в том числе Oracle. Соваться туда маленькой компании или одному человеку просто бессмысленно. Верно, маркетинг найдет слабые стороны и повернет их себе на пользу, только это будет маркетинг Oracle.


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

Вы никогда не интересовались, сколько разработчиков делали kdb, который вы тут как большую компанию приводите? Поинтересуйтесь. Первую версию писал один человек. Сравните с Ораклом. Примеры людей, которых я знаю лично — изначальную версию CQG для микрокомпьютеров сделал в начале 80-х один программист — и CQG . Версию CQG под виндовс в начале 90-х делало двое людей.

Короче, в реальности правила разработки инновационных продуктов и основные факторы успеха совсем не такие, как представляются вам.

Q>Если у тебя конкурентов нет, то

G>>1) это означает отсутствие сформировавшегося рынка, и очень затруднительно достоверно оценить его объем. А это означает, что любая разработка с большими вложениями чрезвычайно рискована. Рынок может быть элемеентарно не готов к твоему решению, если ты опередишь потребности рынка на пару лет — ты пролетишь. Выходить с продуктом надо вовремя. Ты должен очень хорошо представлять себе сбытовую часть в этом случае.
G>>2) Также, отсутствие конкурентов и аналогов афигенно затрудняет анализ требований. Тебе в разы сложнее оценить тенденции пользователей и их потребности.

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


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

G>>Функциональность языка программирования как раз на потребительских ТТХ не сказывается. Почему такая штука, написанная на Эрланге, может иметь преимущество перед остальными существующими решениями, я естественно объяснять не буду. Это элемент технологической стратегии, которую на форумах не обсуждают. Достаточно того, что я сам это понимаю.


Q>Какая штука? Риал-тайм база данных + средства аналитики? Не вижу в этой области у Эрланга никаких преимуществ, тот же ОКамл подошел бы не хуже.


Так это ж здорово, что вы не видите. . Меня это вполне устраивает. И остальных в этом убедите .
Re[17]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 29.11.07 10:48
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Gaperton, Вы писали:


G>>Ну, платить-то можно, это будет даже выгодно. Это нижняя граница коммерческого аутсорсинг-рейта для России. Однако, за эти деньги аутсорсится проект целиком, со всей головной болью. Для удаленного исполнителя, который работает по четким ТЗ и маленьким задачам — это многовато.


Q>Не хотите — не надо, за вычетом налогов, бенефитов и с учетом нестабильности и экзотичности работы, это даже мало.


Ищите тех, кто даст вам больше. какие проблемы? Тока не надо мне рассказывать, что мало, а что много, я в курсе реальных рейтов по удаленным работам. Должность обязывает.
Re[7]: Ищу программирующих на Эрланге
От: Dog  
Дата: 29.11.07 11:58
Оценка: :)
BZ>>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца
JR>Со смогом тут очень плохо.
Два раза прочитал "самогоном"... на канары ни ногой
... << RSDN@Home 1.2.0 alpha rev. 730>>
Re[14]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 29.11.07 15:02
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Вы никогда не интересовались, сколько разработчиков делали kdb, который вы тут как большую компанию приводите? Поинтересуйтесь. Первую версию писал один человек. Сравните с Ораклом. Примеры людей, которых я знаю лично — изначальную версию CQG для микрокомпьютеров сделал в начале 80-х один программист — и CQG . Версию CQG под виндовс в начале 90-х делало двое людей.


Я не приводил kdb в качестве большой компании, не надо приписок. kdb создал себе имя (не говоря уже о том, что этот самый человек сам был известен и занимал большие должности в крупных компаниях до того, как стал работать над kdb) давным давно и работает сейчас за счет репутации и клиентской базы. И то, если такой динозавр как Oracle склепает что-нибудь удобоваримое, то позиции kdb могут серьезно пошатнуться под натиском их сейлзов, несмотря на технологическое преимущество.

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

G>Короче, в реальности правила разработки инновационных продуктов и основные факторы успеха совсем не такие, как представляются вам.


Ну конечно, они такие, как представляются вам. Не напомните, за сколько миллионов продали свою последнюю компанию?
Re[15]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 29.11.07 15:46
Оценка:
Здравствуйте, Quintanar, Вы писали:

G>>Вы никогда не интересовались, сколько разработчиков делали kdb, который вы тут как большую компанию приводите? Поинтересуйтесь. Первую версию писал один человек. Сравните с Ораклом. Примеры людей, которых я знаю лично — изначальную версию CQG для микрокомпьютеров сделал в начале 80-х один программист — и CQG . Версию CQG под виндовс в начале 90-х делало двое людей.


Q>Я не приводил kdb в качестве большой компании, не надо приписок. kdb создал себе имя (не говоря уже о том, что этот самый человек сам был известен и занимал большие должности в крупных компаниях до того, как стал работать над kdb) давным давно и работает сейчас за счет репутации и клиентской базы. И то, если такой динозавр как Oracle склепает что-нибудь удобоваримое, то позиции kdb могут серьезно пошатнуться под натиском их сейлзов, несмотря на технологическое преимущество.


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

Вы пытаетесь сейчас наивными опасениями заменить полновесный анализ рисков и SWOT-анализ. Не переживайте так за kdb, во-первых все факторы рисков касательно Oracle и еще десятки других, которые вы даже представить себе не можете, уже учтены в стратегии kxsolutions, маркетологи которого работают на опережение, оценивая перспективы и тенденции сроком лет на 5 вперед. Представляете — есть специальные люди, которые это умеют, ага. Во-вторых, данная ниша изначально не до такой степени интересна Oracle в силу ну очень небольшого объема рынка в процентах к остальным сегментам, чтобы до такой степени серьезно вкладываться туда, как это делает маленький kxsolutions. Второй факт — также одна из основных универсальных стратегий для маленьких продуктовых компаний.

Хотя, если вдуматься в ваши слова... Если "Динозавр"! "Склепает"!! То тогда сразу и непременно ОООО!!! Всем обкакаться на месте! Я как представил себе такое — так испугался вместе с вами до дрожи в коленках, весь стратегический маркетинг сразу из головы вылетел . Это аргумент, коллега, серьезный аргумент.

Q>А вообще, странные рассуждения, все компании были когда-то небольшими, из этого не следует, что можно сейчас начать делать тоже самое, что они.


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

G>>Короче, в реальности правила разработки инновационных продуктов и основные факторы успеха совсем не такие, как представляются вам.

Q>Ну конечно, они такие, как представляются вам.

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

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

Q>Не напомните, за сколько миллионов продали свою последнюю компанию?

Разумеется, не напомню. Схерали, извините за прямоту?
Re[16]: Ищу программирующих на Эрланге
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 29.11.07 15:55
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>>>Вы никогда не интересовались, сколько разработчиков делали kdb, который вы тут как большую компанию приводите? Поинтересуйтесь. Первую версию писал один человек. Сравните с Ораклом. Примеры людей, которых я знаю лично — изначальную версию CQG для микрокомпьютеров сделал в начале 80-х один программист — и CQG . Версию CQG под виндовс в начале 90-х делало двое людей.


Q>>Я не приводил kdb в качестве большой компании, не надо приписок. kdb создал себе имя (не говоря уже о том, что этот самый человек сам был известен и занимал большие должности в крупных компаниях до того, как стал работать над kdb) давным давно и работает сейчас за счет репутации и клиентской базы. И то, если такой динозавр как Oracle склепает что-нибудь удобоваримое, то позиции kdb могут серьезно пошатнуться под натиском их сейлзов, несмотря на технологическое преимущество.


G>Ой, а ведь правда. А я вот еще тут подумал — а если вдруг разработчику kdb упадет на голову кирпич, и он сыграет в ящик, то тогда ведь позиции kdb могут еще серьезнее пошатнуться .


G>Вы пытаетесь сейчас наивными опасениями заменить полновесный анализ рисков и SWOT-анализ. Не переживайте так за kdb, во-первых все факторы рисков касательно Oracle и еще десятки других, которые вы даже представить себе не можете, уже учтены в стратегии kxsolutions, маркетологи которого работают на опережение, оценивая перспективы и тенденции сроком лет на 5 вперед. Представляете — есть специальные люди, которые это умеют, ага. Во-вторых, данная ниша изначально не до такой степени интересна Oracle в силу ну очень небольшого объема рынка в процентах к остальным сегментам, чтобы до такой степени серьезно вкладываться туда, как это делает маленький kxsolutions. Второй факт — также одна из основных универсальных стратегий для маленьких продуктовых компаний.


G>Хотя, если вдуматься в ваши слова... Если "Динозавр"! "Склепает"!! То тогда сразу и непременно ОООО!!! Всем обкакаться на месте! Я как представил себе такое — так испугался вместе с вами до дрожи в коленках, весь стратегический маркетинг сразу из головы вылетел . Это аргумент, коллега, серьезный аргумент.


Q>>А вообще, странные рассуждения, все компании были когда-то небольшими, из этого не следует, что можно сейчас начать делать тоже самое, что они.


Мне почему-то вспомнилось противостояние Palm и Microsoft на рынке наладонников...


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[16]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 29.11.07 16:52
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ой, а ведь правда. А я вот еще тут подумал — а если вдруг разработчику kdb упадет на голову кирпич, и он сыграет в ящик, то тогда ведь позиции kdb могут еще серьезнее пошатнуться .


Не к лицу клоунада такому крупному и уважаемому специалисту как вы

G>Вы пытаетесь сейчас наивными опасениями заменить полновесный анализ рисков и SWOT-анализ. Не переживайте так за kdb, во-первых все факторы рисков касательно Oracle и еще десятки других, которые вы даже представить себе не можете, уже учтены в стратегии kxsolutions, маркетологи которого работают на опережение, оценивая перспективы и тенденции сроком лет на 5 вперед. Представляете — есть специальные люди, которые это умеют, ага. Во-вторых, данная ниша изначально не до такой степени интересна Oracle в силу ну очень небольшого объема рынка в процентах к остальным сегментам, чтобы до такой степени серьезно вкладываться туда, как это делает маленький kxsolutions. Второй факт — также одна из основных универсальных стратегий для маленьких продуктовых компаний.


Продукт-то они делают (oracle), а когда сделают, придется его продавать. Про объем рынка там тоже подумали, поэтому и делают, они в курсе, что он будет увеличиваться и вытеснять обычные DB.
Про факторы риска, опережение, тенденции, перспективы — это, пожалуйста, в телевизор, я, в отличие от вас, в курсе, в чем недостатки kx и как это может повлиять на их судьбу. Они действительно спокойно жили, пока этот рынок не представлял серьезного интереса для фирм типа MS и Oracle, но поскольку in memory DB сейчас в моде и активно развиваются, спокойная жизнь заканчивается.

G>Хотя, если вдуматься в ваши слова... Если "Динозавр"! "Склепает"!! То тогда сразу и непременно ОООО!!! Всем обкакаться на месте! Я как представил себе такое — так испугался вместе с вами до дрожи в коленках, весь стратегический маркетинг сразу из головы вылетел . Это аргумент, коллега, серьезный аргумент.




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


Да я уже понял, что вы пуп земли.
Re[17]: Ищу программирующих на Эрланге
От: Cyberax Марс  
Дата: 29.11.07 16:57
Оценка: +1
Здравствуйте, Quintanar, Вы писали:

Q>Продукт-то они делают (oracle), а когда сделают, придется его продавать. Про объем рынка там тоже подумали, поэтому и делают, они в курсе, что он будет увеличиваться и вытеснять обычные DB.

Насколько я понимаю, ничего такого сверхнеобычного в kdb нет. Это просто очень хорошо сделаная "колоночная" база данных.

Такой подход известен еще чуть ли не с 80-х, у него тоже свои минусы есть. Обычные "рядовые" БД вытеснять в ближайшем будущем он не будет, разве что в нишевых областях.
Sapienti sat!
Re[17]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 29.11.07 17:39
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Про факторы риска, опережение, тенденции, перспективы — это, пожалуйста, в телевизор, я, в отличие от вас, в курсе, в чем недостатки kx и как это может повлиять на их судьбу.


Можно подробнее про недостатки kx? Если можно так же про то, откуда у вас такие доскональные знания. Последнее можно мылом.

Заранее спасибо!
--
http://wagerlabs.com
Re[17]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 29.11.07 17:49
Оценка:
Здравствуйте, Quintanar, Вы писали:

G>>Ой, а ведь правда. А я вот еще тут подумал — а если вдруг разработчику kdb упадет на голову кирпич, и он сыграет в ящик, то тогда ведь позиции kdb могут еще серьезнее пошатнуться .


Q>Не к лицу клоунада такому крупному и уважаемому специалисту как вы


Отчего бы не подурачится, с другой стороны.

G>>Вы пытаетесь сейчас наивными опасениями заменить полновесный анализ рисков и SWOT-анализ. Не переживайте так за kdb, во-первых все факторы рисков касательно Oracle и еще десятки других, которые вы даже представить себе не можете, уже учтены в стратегии kxsolutions, маркетологи которого работают на опережение, оценивая перспективы и тенденции сроком лет на 5 вперед. Представляете — есть специальные люди, которые это умеют, ага. Во-вторых, данная ниша изначально не до такой степени интересна Oracle в силу ну очень небольшого объема рынка в процентах к остальным сегментам, чтобы до такой степени серьезно вкладываться туда, как это делает маленький kxsolutions. Второй факт — также одна из основных универсальных стратегий для маленьких продуктовых компаний.


Q>Продукт-то они делают (oracle), а когда сделают, придется его продавать. Про объем рынка там тоже подумали, поэтому и делают, они в курсе, что он будет увеличиваться и вытеснять обычные DB.


Нет, они не в курсе, это для них большая новость. Потому, что не смогут базы данных, ориентированные на обработку time series, вытеснить обычные БД. У них принципиально разные области применения, которые слабо пересекаются.

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

Q>Про факторы риска, опережение, тенденции, перспективы — это, пожалуйста, в телевизор, я, в отличие от вас, в курсе, в чем недостатки kx и как это может повлиять на их судьбу. Они действительно спокойно жили, пока этот рынок не представлял серьезного интереса для фирм типа MS и Oracle, но поскольку in memory DB сейчас в моде и активно развиваются, спокойная жизнь заканчивается.


В отличии от вас, я в работая в CQG такой сервер писал, так понтоваться не рекомендую, говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт. in memory DB не подходят для биржевых приложений. Сколько, по вашему занимает один день котировок с одной биржи, интересно, и как вы думаете — влезет ли он в память. 50К контрактов, примерно 30 миллионов котировок — нормально для хорошей электронной биржи. По 10 байт на котировку (4 байта price + 4 байта volume + 1 байт флаги + 1 байт секунды) это почти без компрессии и индексов — на самом деле больше будет) — 300 мегабайт. Сколько в мире крупных бирж? Положим, штук 20. Валяйте, храните в памяти. Ой какая крупная угроза идет со стороны in-memory database, уписаться.

G>>Хотя, если вдуматься в ваши слова... Если "Динозавр"! "Склепает"!! То тогда сразу и непременно ОООО!!! Всем обкакаться на месте! Я как представил себе такое — так испугался вместе с вами до дрожи в коленках, весь стратегический маркетинг сразу из головы вылетел . Это аргумент, коллега, серьезный аргумент.


Q>


Смешно.

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


Q>Да я уже понял, что вы пуп земли.


Не удивительно, вам вообще сложно что-либо объяснить. Вы должны были понять, что изволите спорить со мной сразу по двум темам, которые являются моей прямой специальностью. 6 лет в CQG я занимался разработкой их сервера БД для time series и финансовых приложений, и последние два года я профессионально занимаюсь стратегическим и продуктовым маркетингом и всякими там бизнес-стратегиями. Я в Эрланге и ФП гораздо меньше соображаю, право, чем по этим темам .
Re[18]: Ищу программирующих на Эрланге
От: dmz Россия  
Дата: 30.11.07 03:27
Оценка:
G>Не удивительно, вам вообще сложно что-либо объяснить. Вы должны были понять, что изволите спорить со мной сразу по G>двум темам, которые являются моей прямой специальностью. 6 лет в CQG я занимался разработкой их сервера БД для G>time series и финансовых приложений, и последние два года я профессионально занимаюсь стратегическим и продуктовым G>маркетингом и всякими там бизнес-стратегиями. Я в Эрланге и ФП гораздо меньше соображаю, право, чем по этим темам

Дикий офтоп, но поскольку другие способы связаться не возымели успеха, пишу здесь.
Gaperton! Очень нужно с тобой связаться, обсудить возможность консультации. Я таки ввязался в разработку части проекта на Эрланге, и хотя получилось так, что эта часть будет намного менее критичной, чем казалось ранее, и ее можно будет просто выкинуть, в крайнем случае, но хочется все сделать все хорошо сразу. Как можно связаться?
Re[18]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 30.11.07 08:06
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Насколько я понимаю, ничего такого сверхнеобычного в kdb нет. Это просто очень хорошо сделаная "колоночная" база данных.


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

C>Такой подход известен еще чуть ли не с 80-х, у него тоже свои минусы есть. Обычные "рядовые" БД вытеснять в ближайшем будущем он не будет, разве что в нишевых областях.


Я не утверждал, что kdb всех вытеснит, я хотел сказать, что колоночные in memory базы данных получают все большее распространение. Поскольку память растет и дешевеет, то у них большое будущее, на мой взгляд.
Re[18]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 30.11.07 08:31
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>В отличии от вас, я в работая в CQG такой сервер писал, так понтоваться не рекомендую, говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт. in memory DB не подходят для биржевых приложений. Сколько, по вашему занимает один день котировок с одной биржи, интересно, и как вы думаете — влезет ли он в память. 50К контрактов, примерно 30 миллионов котировок — нормально для хорошей электронной биржи. По 10 байт на котировку (4 байта price + 4 байта volume + 1 байт флаги + 1 байт секунды) это почти без компрессии и индексов — на самом деле больше будет) — 300 мегабайт. Сколько в мире крупных бирж? Положим, штук 20. Валяйте, храните в памяти. Ой какая крупная угроза идет со стороны in-memory database, уписаться.


Я то как раз могу попонтоваться, поскольку прямо сейчас могу посмотреть котировки какого-нибудь MSFT за любую дату. И хранятся они (сюрприз!) в базе данных, без всякого сжатия. Таблица котировок занимает гигабайт 7-8 на диске за средний день для ведущих бирж США (CTS + NASD). Много, конечно, но если на машине стоит 32-64 гигабайт памяти, то уже нормально. Если вам не давали купить память и приходилось извращаться и ужиматься в 4 гигабайта (надеюсь хоть машина была 64-х битная), то это ваши проблемы, это никак не опровергает того, что все данные по всем биржам мира за день можно уместить в памяти 3-х серверов и то ради удобства.

G>Не удивительно, вам вообще сложно что-либо объяснить. Вы должны были понять, что изволите спорить со мной сразу по двум темам, которые являются моей прямой специальностью. 6 лет в CQG я занимался разработкой их сервера БД для time series и финансовых приложений, и последние два года я профессионально занимаюсь стратегическим и продуктовым маркетингом и всякими там бизнес-стратегиями. Я в Эрланге и ФП гораздо меньше соображаю, право, чем по этим темам .


Первое и моя специальность, не вижу причин, почему ваш локальный опыт лучше моего.
Re[18]: Оффтоп
От: Shota  
Дата: 30.11.07 09:23
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт.

Не могли бы вы рассказать, какие готовые time series БД существуют, более доступные и открытые, чем kdb? Тоже работаю в это области, есть свои наработки/велосипеды по хранению биржевых данных, хочу сравнить с другими системами. Недавно гуглил, но что-то ничего приличного из time series db не нашел .
Re[19]: Оффтоп
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 09:44
Оценка:
Здравствуйте, Shota, Вы писали:

G>>говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт.

S>Не могли бы вы рассказать, какие готовые time series БД существуют, более доступные и открытые, чем kdb? Тоже работаю в это области, есть свои наработки/велосипеды по хранению биржевых данных, хочу сравнить с другими системами. Недавно гуглил, но что-то ничего приличного из time series db не нашел .

По состоянию на 2001 год, когда мы проводили исследование предложения, специализированных движков кроме kdb не было. Кроме kdb, Informix давал datablade для timeseries, который нас сильно расстроил тогда. От kdb отказались, так как у нас весьма конкретные и специфические требования к движку, и готовый сервер приложеений, и мы вовсе не были уверены, что kdb адекватно выполнит все наши use cases. Например, CQG сервер не делает разницы между real time и historical данными — для него это фактически одно и то же, и все обновления происходят в реальном времени. Это очень нравится трейдерам, у конкурентов такого не было тогда.

Прототип на MS SQL показан неудовлетворительные результаты. Производительность просаживалась на межпроцессной передаче на порядок, ужасно медленно — практически внятяг по требованиям, обновлялись котировки в базе (и это после танцев с бубном). Язык запросов мешает, а не помогает. Мы его делали с одним парнем, который был MCSD. В результате, решили просто искать простой встраиваемый движок БД, поверх которого можно эффективно навернуть свой time series движок ручками.

Что мы выбрали в результате сказать не могу, извините. Насчет ситуации по движкам time series сейчас — я ее не отслеживал, но мой бывший коллега-MCSD, который сейчас делает решения для брокеров и автоматической торговли, говорит, что ситуация с тех пор изменилась не сильно.
Re[19]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 09:45
Оценка:
Здравствуйте, dmz, Вы писали:

dmz>Дикий офтоп, но поскольку другие способы связаться не возымели успеха, пишу здесь.

dmz>Gaperton! Очень нужно с тобой связаться, обсудить возможность консультации. Я таки ввязался в разработку части проекта на Эрланге, и хотя получилось так, что эта часть будет намного менее критичной, чем казалось ранее, и ее можно будет просто выкинуть, в крайнем случае, но хочется все сделать все хорошо сразу. Как можно связаться?

Пиши на gaperton at gmail dot com.
Re[20]: Оффтоп
От: Shota  
Дата: 30.11.07 10:12
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Прототип на MS SQL показан неудовлетворительные результаты. Производительность просаживалась на межпроцессной передаче на порядок, ужасно медленно — практически внятяг по требованиям, обновлялись котировки в базе (и это после танцев с бубном). Язык запросов мешает, а не помогает. Мы его делали с одним парнем, который был MCSD. В результате, решили просто искать простой встраиваемый движок БД, поверх которого можно эффективно навернуть свой time series движок ручками.


Аналогично пробовали сначала с Firebird — скорость никакая, притом база быстро разрастается. Сейчас у нас двухуровневое решение — долговременное медленное хранилише со сжатием + кратковременный кеш на файл-маппинговом векторообразном контейнере. Насколько этот подход плох/хорош по вашему?

Меня этот вопрос еще вот с какой стороны интересует. Обчитавшись ДП и поверив в крутизну Эрланга , я задумал реализовать на нем наш сервер, чтобы упростить работу со многими клиентами, в часности, да и cpp-specific баги надоели . Однако уперся в работу с нашим хранилишем. Сейчас, с использованием файл-маппинга, расход RAM очень небольшой, по программе гуляют оберточные структуры. Причем ненужные файлы можно детерминированно выгружать из адресного пространства, без этого оно быстро кончится. Как с этии делом в Эрланге? Насколько я понимаю, такие трюки и автосборка мусора не очень совместимы... Жду совета от гуру .
Re[19]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 10:24
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Gaperton, Вы писали:


G>>В отличии от вас, я в работая в CQG такой сервер писал, так понтоваться не рекомендую, говоря о БД для обработки time series — вы на моей территории, там, где я реально эксперт. in memory DB не подходят для биржевых приложений. Сколько, по вашему занимает один день котировок с одной биржи, интересно, и как вы думаете — влезет ли он в память. 50К контрактов, примерно 30 миллионов котировок — нормально для хорошей электронной биржи. По 10 байт на котировку (4 байта price + 4 байта volume + 1 байт флаги + 1 байт секунды) это почти без компрессии и индексов — на самом деле больше будет) — 300 мегабайт. Сколько в мире крупных бирж? Положим, штук 20. Валяйте, храните в памяти. Ой какая крупная угроза идет со стороны in-memory database, уписаться.


Q>Я то как раз могу попонтоваться, поскольку прямо сейчас могу посмотреть котировки какого-нибудь MSFT за любую дату.

Не, так не пойдет. Это ж каждый может — online через futuresource или yahoo stocks . Ты вместо настоящих ядреных понтов какою-то ерунду мне хочешь подсунуть — расстройство одно. Я так понимаю, раз понты — так понты, блин, взялся — так уж будь любезен постарайся как следует. Короче, жду настоящих, серьезных понтов.

Q>И хранятся они (сюрприз!) в базе данных, без всякого сжатия.

Это для меня очень хорошая новость. Это меня радует .

Q>Таблица котировок занимает гигабайт 7-8 на диске за средний день для ведущих бирж США (CTS + NASD).

Q>Много, конечно, но если на машине стоит 32-64 гигабайт памяти, то уже нормально. Если вам не давали купить память и приходилось извращаться и ужиматься в 4 гигабайта (надеюсь хоть машина была 64-х битная), то это ваши проблемы, это никак не опровергает того, что все данные по всем биржам мира за день можно уместить в памяти 3-х серверов и то ради удобства.

Мне как раз кажется извращением стараться уместить котировки в памяти.

Во-первых, насколько я припоминаю, каждый сервер CQG по правилам 2005 года должен хранить истории котировок за 10 лет по всем крупным биржам мира. А в мире, если мне не изменяет память, примерно двадцать крупных бирж, не считая мелких, которые тоже не фигово хранить.

Во вторых — ни единого резона держать котировки в памяти нет. При желании, мы можем читать их с диска раз как минимум в десять быстрее, чем их в состоянии обрабатывать торговые роботы. Только по понятным причинам это нахрен никому не нужно, тем более — держать в памяти их BD. Что касается тех редких ситуаций, когда это реально требуется (не припомню таких ярковыраженных случаев, кстати, поправьте меня, очень интересно увидеть контрпример), достаточно простого кэширования котировок и агрегатов OHLC в памяти по сегментам. Не нужна никакая in-memory DB.

G>>Не удивительно, вам вообще сложно что-либо объяснить. Вы должны были понять, что изволите спорить со мной сразу по двум темам, которые являются моей прямой специальностью. 6 лет в CQG я занимался разработкой их сервера БД для time series и финансовых приложений, и последние два года я профессионально занимаюсь стратегическим и продуктовым маркетингом и всякими там бизнес-стратегиями. Я в Эрланге и ФП гораздо меньше соображаю, право, чем по этим темам .


Q>Первое и моя специальность, не вижу причин, почему ваш локальный опыт лучше моего.

Гхм, то есть по второй — возражений нет? . Quintanar, я очень хорошо к вам отношусь, на самом деле. И я не собираюсь утверждать, что мой опыт в первой специальности лучше вашего. Вы первым начали . А я вам показываю, что меня за совсем лоха-то тоже не надо держать. Вот и получился замер пиписьками . Весело. Продолжим?
Re[21]: Оффтоп
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 10:35
Оценка:
Здравствуйте, Shota, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:


G>>Прототип на MS SQL показан неудовлетворительные результаты. Производительность просаживалась на межпроцессной передаче на порядок, ужасно медленно — практически внятяг по требованиям, обновлялись котировки в базе (и это после танцев с бубном). Язык запросов мешает, а не помогает. Мы его делали с одним парнем, который был MCSD. В результате, решили просто искать простой встраиваемый движок БД, поверх которого можно эффективно навернуть свой time series движок ручками.


S>Аналогично пробовали сначала с Firebird — скорость никакая, притом база быстро разрастается. Сейчас у нас двухуровневое решение — долговременное медленное хранилише со сжатием + кратковременный кеш на файл-маппинговом векторообразном контейнере. Насколько этот подход плох/хорош по вашему?


Вполне нормальный подход. На самом деле — зависит от use cases.

S>Меня этот вопрос еще вот с какой стороны интересует. Обчитавшись ДП и поверив в крутизну Эрланга ,

Черт, ну зачем я с Quintanar спорю? Надо было сразу сдаться. Дурак.

S>я задумал реализовать на нем наш сервер, чтобы упростить работу со многими клиентами, в часности, да и cpp-specific баги надоели . Однако уперся в работу с нашим хранилишем. Сейчас, с использованием файл-маппинга, расход RAM очень небольшой, по программе гуляют оберточные структуры. Причем ненужные файлы можно детерминированно выгружать из адресного пространства, без этого оно быстро кончится.


Я бы посоветовал завернуть ваше хранилище в драйвер или C-node.

S>Как с этии делом в Эрланге? Насколько я понимаю, такие трюки и автосборка мусора не очень совместимы... Жду совета от гуру .


Я не гуру в Эрланге, я только учусь. К тому же, я не хочу обсуждать технологию хранения биржевых данных в Эрланге, пока я не сделал свой прототип. Когда я буду уверен, что не собираюсь делать на нем движок биржевой обработки — тогда можно будет поговорить. Тем более — скажу правду и только правду — мне самому надо сделать серию прототипов, чтобы выбрать способ работы с данными. Я пока не знаю точно, как надо.
Re[20]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 30.11.07 14:18
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Не, так не пойдет. Это ж каждый может — online через futuresource или yahoo stocks . Ты вместо настоящих ядреных понтов какою-то ерунду мне хочешь подсунуть — расстройство одно. Я так понимаю, раз понты — так понты, блин, взялся — так уж будь любезен постарайся как следует. Короче, жду настоящих, серьезных понтов.


Ну я, прям, даже не знаю.

Q>>И хранятся они (сюрприз!) в базе данных, без всякого сжатия.

G>Это для меня очень хорошая новость. Это меня радует .

А в чем радость? Реально не вижу смысла в сжатии, это усложняет загрузку/сохранение и, фактически, лишает смысла колоночную организацию хранения и mmap.

G>Мне как раз кажется извращением стараться уместить котировки в памяти.

G>Во-первых, насколько я припоминаю, каждый сервер CQG по правилам 2005 года должен хранить истории котировок за 10 лет по всем крупным биржам мира. А в мире, если мне не изменяет память, примерно двадцать крупных бирж, не считая мелких, которые тоже не фигово хранить.

В памяти достаточно хранить данные за текущий день, потому как
1) их необходимо обновлять в real-time, т.е. обрабатывать сотни миллионов сообщений в день.
2) они наиболее часто используются
остальные грузятся по мере необходимости и потом выгружаются.
10-ть лет в 2005 году — это террабайт 10, столько в память никогда не уместить. Но это и не надо, столь старые данные используются очень редко.

G>Во вторых — ни единого резона держать котировки в памяти нет. При желании, мы можем читать их с диска раз как минимум в десять быстрее, чем их в состоянии обрабатывать торговые роботы. Только по понятным причинам это нахрен никому не нужно, тем более — держать в памяти их BD. Что касается тех редких ситуаций, когда это реально требуется (не припомню таких ярковыраженных случаев, кстати, поправьте меня, очень интересно увидеть контрпример), достаточно простого кэширования котировок и агрегатов OHLC в памяти по сегментам. Не нужна никакая in-memory DB.


Вам не нужна, а нам нужна. Клиенты пользуются и не жалуются, им очень нравится скорость работы. Не могу понять, в чем состоит аргумент против БД. Единственный минус — стоимость обрудования и лицензии на ПО. Но если писать самим, то выгоды особой не будет все равно.
К тому же, я еще раз обращаю внимание, к БД прилагается еще очень мощный язык, который в своей области вне конкуренции. Он позволяет сделать с данными, что угодно, без необходимости что-то писать на С/C++/Java. Векторный Lisp по сути дела.
Вероятно, разногласия вызывает in memory. In memory она в том смысле, что все данные, кроме огромных исторических таблиц хранятся в памяти. История грузится по мере использования.
Re[21]: Ищу программирующих на Эрланге
От: Joel Reymont Испания http://wagerlabs.com
Дата: 30.11.07 15:03
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>Вам не нужна, а нам нужна. Клиенты пользуются и не жалуются, им очень нравится скорость работы. Не могу понять, в чем состоит аргумент против БД. Единственный минус — стоимость обрудования и лицензии на ПО. Но если писать самим, то выгоды особой не будет все равно.

Q>К тому же, я еще раз обращаю внимание, к БД прилагается еще очень мощный язык, который в своей области вне конкуренции. Он позволяет сделать с данными, что угодно, без необходимости что-то писать на С/C++/Java. Векторный Lisp по сути дела.

Мне очень интересно узнать где Вы работаете и подробности про kbd. Я предполагаю, что именно о ней Вы говорите выше.

Свяжитесь со мной, если не сложно, joel r1 a t gmail com.
--
http://wagerlabs.com
Re[22]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 30.11.07 15:15
Оценка:
Здравствуйте, Joel Reymont, Вы писали:

JR>Свяжитесь со мной, если не сложно, joel r1 a t gmail com.


Хорошо, я просто не могу написать с работы (закрыт доступ к почт. сайтам).
Re[21]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 15:29
Оценка:
Здравствуйте, Quintanar, Вы писали:

Q>>>И хранятся они (сюрприз!) в базе данных, без всякого сжатия.

G>>Это для меня очень хорошая новость. Это меня радует .

Q>А в чем радость? Реально не вижу смысла в сжатии, это усложняет загрузку/сохранение и, фактически, лишает смысла колоночную организацию хранения и mmap.


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

G>>Мне как раз кажется извращением стараться уместить котировки в памяти.

G>>Во-первых, насколько я припоминаю, каждый сервер CQG по правилам 2005 года должен хранить истории котировок за 10 лет по всем крупным биржам мира. А в мире, если мне не изменяет память, примерно двадцать крупных бирж, не считая мелких, которые тоже не фигово хранить.

Q>В памяти достаточно хранить данные за текущий день, потому как

Q>1) их необходимо обновлять в real-time, т.е. обрабатывать сотни миллионов сообщений в день.
Обновлять тебе надо в 99 и 99999 % случаев только последнюю минуту, последовательно добавляя котировки. corrections редки для неэлектронных бирж, и практически отсуствуют для электронных, и для их обработки в любом случае нет real-time требований. Делайте выводы.

Q>2) они наиболее часто используются

Кем используются? Роботы историей котировок не пользуются, они на enevt-ах построены. Для исторической же аналитики применяются не котировки, а intraday и daily ohlc bars. Которые 1) не критичны к скорости построения, и 2) их, если вдуматься, можно очень по разному строить. Тоже пока не буду говорить, как.

Тем более, что обычно одновременно используются небольшой процент контрактов с биржи, занимать память на всякий случай под все — зачем?

Откровенно говоря, такой подход в kdb меня тоже сильно радует. Это означает, что характеристик движка kdb можно не слишком бояться — как-то слишком в лоб у них это сделано. Даже не верится. Реальная проблема — это их язык запросов. Но тут мы еще посмотрим, кто кого.

Q>остальные грузятся по мере необходимости и потом выгружаются.

Само собой.

Q>10-ть лет в 2005 году — это террабайт 10, столько в память никогда не уместить. Но это и не надо, столь старые данные используются очень редко.

Разумеется. Я это к тому привел, что in-memory DB вам не сильно поможет в данных задачах.

G>>Во вторых — ни единого резона держать котировки в памяти нет. При желании, мы можем читать их с диска раз как минимум в десять быстрее, чем их в состоянии обрабатывать торговые роботы. Только по понятным причинам это нахрен никому не нужно, тем более — держать в памяти их BD. Что касается тех редких ситуаций, когда это реально требуется (не припомню таких ярковыраженных случаев, кстати, поправьте меня, очень интересно увидеть контрпример), достаточно простого кэширования котировок и агрегатов OHLC в памяти по сегментам. Не нужна никакая in-memory DB.


Q>Вам не нужна, а нам нужна. Клиенты пользуются и не жалуются, им очень нравится скорость работы. Не могу понять, в чем состоит аргумент против БД. Единственный минус — стоимость обрудования и лицензии на ПО. Но если писать самим, то выгоды особой не будет все равно.


To make the things clear. Я не против kdb. Я считаю ее хорошим продуктом. Но я уверен, что учтя нюансы предметной области и используя свой опыт работы над сервером БД CQG смогу сделать лучше. И дешевле. Тут даже дело не столько в Эрланге. Сделать просто just for fun, но если получится хорошо — то можно попробовать и продать.

Q>К тому же, я еще раз обращаю внимание, к БД прилагается еще очень мощный язык, который в своей области вне конкуренции. Он позволяет сделать с данными, что угодно, без необходимости что-то писать на С/C++/Java. Векторный Lisp по сути дела.


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

Эти две темы — сервер котировок и встроенный язык — и были моей основной специализацией в CQG. Собственно, я был ведущим спецом именно по этим двум темам, и был тимлидом соответствующей группы разработки. По другим темам там были другие ведущие спецы, тем в CQG дохрена, как и ведущих спецов.

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

Q>Вероятно, разногласия вызывает in memory. In memory она в том смысле, что все данные, кроме огромных исторических таблиц хранятся в памяти. История грузится по мере использования.


Разумеется, если они в память не влезают, то как еще.
Re[22]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 30.11.07 16:08
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Ну как сказать, просто есть разные подходы к хранению котировок. И меня очень радует тот факт, что в kdb применяется именно такой подход. Я уже вижу, как ее порвать на британский флаг на обработке котировок. Вот и радуюсь. Говорить пока не буду — во-первых, еще не порвал, во-вторых — пусть это будет моим маленьким секретом до поры.


Хех, флаг в руки!

G>Обновлять тебе надо в 99 и 99999 % случаев только последнюю минуту, последовательно добавляя котировки. corrections редки для неэлектронных бирж, и практически отсуствуют для электронных, и для их обработки в любом случае нет real-time требований. Делайте выводы.


Недооцениваете количество corrections/cancelations. Реально их много, причем именно на электронных биржах. Особенно много на ADF. Но это, действительно, не существенно.

G>Кем используются? Роботы историей котировок не пользуются, они на enevt-ах построены. Для исторической же аналитики применяются не котировки, а intraday и daily ohlc bars. Которые 1) не критичны к скорости построения, и 2) их, если вдуматься, можно очень по разному строить. Тоже пока не буду говорить, как.

G>Тем более, что обычно одновременно используются небольшой процент контрактов с биржи, занимать память на всякий случай под все — зачем?
G>Откровенно говоря, такой подход в kdb меня тоже сильно радует. Это означает, что характеристик движка kdb можно не слишком бояться — как-то слишком в лоб у них это сделано. Даже не верится. Реальная проблема — это их язык запросов. Но тут мы еще посмотрим, кто кого.

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

G>Эти две темы — сервер котировок и встроенный язык — и были моей основной специализацией в CQG. Собственно, я был ведущим спецом именно по этим двум темам, и был тимлидом соответствующей группы разработки. По другим темам там были другие ведущие спецы, тем в CQG дохрена, как и ведущих спецов.

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

Попробуйте, попробуйте. Мне тоже очень приятна такая недооценка kdb-шного подхода. Тред выявил факт, что люди мало того, что не в курсе как оно бывает, так еще и не верят в эффективность метода.
Re[20]: Оффтоп
От: awson  
Дата: 30.11.07 17:24
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Насчет ситуации по движкам time series сейчас — я ее не отслеживал, но мой бывший коллега-MCSD, который сейчас делает решения для брокеров и автоматической торговли, говорит, что ситуация с тех пор изменилась не сильно.


Что думаете насчет Vertica? Это commercialization of the C-Store. Там и in-memory и компрессия. То же — пока (возможно, никогда) не открытая разновидность MonetDB — X100.
Re[23]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 18:22
Оценка:
G>>Обновлять тебе надо в 99 и 99999 % случаев только последнюю минуту, последовательно добавляя котировки. corrections редки для неэлектронных бирж, и практически отсуствуют для электронных, и для их обработки в любом случае нет real-time требований. Делайте выводы.

Q>Недооцениваете количество corrections/cancelations. Реально их много, причем именно на электронных биржах. Особенно много на ADF. Но это, действительно, не существенно.


А Cancellations не надо резолвить при получении, зачем мне их учитывать. Их надо записывать так же, как и трейды. По другому некорректно.

G>>Кем используются? Роботы историей котировок не пользуются, они на enevt-ах построены. Для исторической же аналитики применяются не котировки, а intraday и daily ohlc bars. Которые 1) не критичны к скорости построения, и 2) их, если вдуматься, можно очень по разному строить. Тоже пока не буду говорить, как.

G>>Тем более, что обычно одновременно используются небольшой процент контрактов с биржи, занимать память на всякий случай под все — зачем?
G>>Откровенно говоря, такой подход в kdb меня тоже сильно радует. Это означает, что характеристик движка kdb можно не слишком бояться — как-то слишком в лоб у них это сделано. Даже не верится. Реальная проблема — это их язык запросов. Но тут мы еще посмотрим, кто кого.

Q>Данные в памяти дают скорость. Не знаю, сколько у вас было клиентов, если мало, то такие рассуждения имеют право на существование, но когда к данным рвутся многие люди из разных отделов, которым надо разные данные, то желательно держать данные в памяти. Я тут посмотрел, типичный запрос выполняется меньше 100 миллисекунд.


У нас на одной чикагской ферме 2000 клиентов висит одновременно. Так, для справки. CQG это не частная трейдерская конторка с отделами, это фид провайдер и сервис провайдер для профессиональных трейдеров и организаций в первой пятерке в США. Конкурирует с Bloomberg, reuters, и Trading Station.
Терминал CQG, который подсоединен к ферме, выполняющей мой код каждую секунду, вы найдете в любом крупном банке.

G>>Эти две темы — сервер котировок и встроенный язык — и были моей основной специализацией в CQG. Собственно, я был ведущим спецом именно по этим двум темам, и был тимлидом соответствующей группы разработки. По другим темам там были другие ведущие спецы, тем в CQG дохрена, как и ведущих спецов.

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

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


Понимаете, какая между нами разница. Вы пользователь движка БД, а я их проектировщик . Вы только что дали мне достаточную информацию, по которой я уже могу оценить сильные и слабые стороны Kdb. Умею, понимаете? Вот все разное умеют, а я — это .
Re[24]: Ищу программирующих на Эрланге
От: Quintanar Россия  
Дата: 30.11.07 22:26
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>У нас на одной чикагской ферме 2000 клиентов висит одновременно. Так, для справки. CQG это не частная трейдерская конторка с отделами, это фид провайдер и сервис провайдер для профессиональных трейдеров и организаций в первой пятерке в США. Конкурирует с Bloomberg, reuters, и Trading Station.

G>Терминал CQG, который подсоединен к ферме, выполняющей мой код каждую секунду, вы найдете в любом крупном банке.

Не знаю. Bloomberg дает более качественные данные (его принято считать за эталон), у нас используется reuters для фидов, в перспективе, возможно, другие провайдеры, но о CQG речи не шло.

G>Понимаете, какая между нами разница. Вы пользователь движка БД, а я их проектировщик . Вы только что дали мне достаточную информацию, по которой я уже могу оценить сильные и слабые стороны Kdb. Умею, понимаете? Вот все разное умеют, а я — это .


Я вам не дал никакой информации, в том то и дело. Вы не знаете реально, как работает kdb, а имеете лишь приблизительное представление, искаженное вашими предрассудками.

И вот, реально, объясните зачем нужен Эрланг. Его главное преимущество — это параллельные процессы, как раз то, что не играет никакой роли в обработке униформных огромных объемов данных. Действительная арифметика там отстой, векторизации никакой нет, структуры данных типа таблиц не поддерживаются. Т.е. торможение во всем, а выгоды нет.
Re[25]: Ищу программирующих на Эрланге
От: Gaperton http://gaperton.livejournal.com
Дата: 30.11.07 23:41
Оценка:
Здравствуйте, Quintanar, Вы писали:

G>>Терминал CQG, который подсоединен к ферме, выполняющей мой код каждую секунду, вы найдете в любом крупном банке.


Q>Не знаю. Bloomberg дает более качественные данные (его принято считать за эталон), у нас используется reuters для фидов, в перспективе, возможно, другие провайдеры, но о CQG речи не шло.


Фид Cqg на CBOT принят как эталон и применяется при разрешении споров. У Cqg очень качественный фид. Единственное — опционный фид говно, там биды с асками не отменяются, как в блумберге.

G>>Понимаете, какая между нами разница. Вы пользователь движка БД, а я их проектировщик . Вы только что дали мне достаточную информацию, по которой я уже могу оценить сильные и слабые стороны Kdb. Умею, понимаете? Вот все разное умеют, а я — это .


Q>Я вам не дал никакой информации, в том то и дело. Вы не знаете реально, как работает kdb, а имеете лишь приблизительное представление, искаженное вашими предрассудками.


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

Q>И вот, реально, объясните зачем нужен Эрланг. Его главное преимущество — это параллельные процессы, как раз то, что не играет никакой роли в обработке униформных огромных объемов данных. Действительная арифметика там отстой, векторизации никакой нет, структуры данных типа таблиц не поддерживаются. Т.е. торможение во всем, а выгоды нет.


Хо-хо Не забывайте, что на очень тормозном эрланге сделан самый быстрый АТМ софтсвитч Axd301.

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

Короче, не учитываете вы близость телекомовских и финансовых требований.

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

Так что есть кое-какие ходы. Почитайте диссертацию Армстронга.
Re[21]: Оффтоп
От: Gaperton http://gaperton.livejournal.com
Дата: 03.12.07 10:42
Оценка: 16 (1)
Здравствуйте, awson, Вы писали:

A>Здравствуйте, Gaperton, Вы писали:


G>>Насчет ситуации по движкам time series сейчас — я ее не отслеживал, но мой бывший коллега-MCSD, который сейчас делает решения для брокеров и автоматической торговли, говорит, что ситуация с тех пор изменилась не сильно.


A>Что думаете насчет Vertica? Это commercialization of the C-Store. Там и in-memory и компрессия. То же — пока (возможно, никогда) не открытая разновидность MonetDB — X100.


Vertica — выглядит как ацкая штука. У них в основателях сам Стоунбрейкер. Это звучит очень страшно на первый взгляд — прям также, как и "динозавр" "наклепает". О-о-о! Но давайте почитаем их white paper. Бояться не надо, надо знать.

Column-orientation
Since many database queries are “disk bound”, meaning D > C, the most obvious performance
advantage of Vertica is that it only needs to read the two columns involved in the query from disk.
In a traditional row-oriented database, the disk would need to scan over all five columns.

Для справки: все современные взрослые сервера реляционных баз данных (я говорю об Oracl, MS SQL, Sybase) используют именно такое представление спокон веков. Единственным заметным исключением является MySQG со своим InnoDB, где данные хранятся построчно. И разработчики рефлексируют на эту тему в соответствующих White Papers.

Но кстати, именно в финансовых приложений от такого представления толку полный ноль, там как раз выгоднее хранить данные построчно. Колонок, видите-ли немного. И количество популярных вариантов выборок совсем небольшое.

Aggressive Compression
Мурашки по коже. Ну все, концы. Читаем дальше.

This means that, rather than representing the price column as a list of the form
(price1, price1, ...., price2, price2, ... ), we can represent it as a run-length encoded (RLE) list of
the form (<count, price1>, <count, price2>, ....), which will be about 27 times smaller than the
initial representation.

Гы-гы-гы! От такой наивной компрессии на реальных котировках толку немного — повторение цен редко, цену постоянно колбасит вверх-вниз. Особенно, если хранить биды/аски в одной таблице с трейдами. К примеру, схемы компрессии, которые разрабатывались и применялись в моей группе, дают устойчивые коэффициенты компрессии в 4 раза на реальных котировках без повторений цены (плотнее ужать невозможно в принципе), при этом просты как топор и совершенно не нагружают ЦП.

То же самое касается компрессии LZ. Мимо.

А вот Delta Compression — это уже больше подходит к задаче. Это уже серьезно. Только есть нюанс — база не знает, что хранит временной ряд котировок. Зная это, они могли бы сделать эффективную схему компрессии, полагаясь на физическую упорядоченность данных по этому критерию, одновременно привязав к нему схему хранения данных на диске, а не зная этого — эффективную и простую схему компрессии сделать очень сложно (я бы сказал, в данной области универсальное решение будет сложнее и заметно проиграет по эффективности специализированному).

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

Тестам производительности и цифрам "ускорения" из white papers доверять нельзя — они не сообщают не то что информацию о тестах, но даже на каких классах финансовых приложений они это меряют.

В реальности, для out of process серверов финансовых данных основная проблема — даже не сжатие котировок, а скорость межпроцессного обмена. Вся прозводительность убьется на межпроцессной передаче. MS SQL, к примеру, теряет на ней производительность в 10 раз на финансовых задачах. И при этом смысла нет application server крутить целиком на хранимых процедурах — это очень геморройно.

kdb в целом выглядит существенно лучше. Он по крайней мере знает, что хранит временной ряд котировок, и у них есть готовые решения для финансовой области, начиная от парсеров фидов. А Vertica надо еще напильником допиливать, делая всю основную работу самому.

Короче, если работаешь в трейдерской компании, и не занимаешься профессионально разработкой движков БД в этой области — Vertico можно включить в рассмотрение, Oracle и MS SQL она судя по всему побьет. Но все это стадо на этом поле все равно отимеет kdb. Для компании-разработчика трейдерских технологий, таких как FutureSource, CQG, TradingStation — проще и лучше использовать качественный и простой in-process ISAM-движок.

MonetDB — вообще совершенно непонятно, почему должна подойти для финансовых приложений. Сложных запросов к данным, которые так классно типа выполняет MonetDB, и в чем ее основная рекламируемая фишка — в финансовых приложениях нет. Живет она в отдельном процессе, что либо замедлит обработку, либо вынудит весь сервер писать на хранимых процедурах или плагинах к MonetDB — ай как нехорошо, проще воспользоваться простой базой ISAM. Все запросы предельно тупые, в 99,9% случаев выполняются в одну пробежку по одной таблице. Не нужна и колоночная организация, от нее ноль бенефита. Не нужна in-memory database — все можно вполне успешно хранить на дисках, скорости хватит с избытком.
Re[26]: Ищу программирующих на Эрланге
От: ironwit Украина  
Дата: 07.01.08 10:22
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, Quintanar, Вы писали:

Q>>И вот, реально, объясните зачем нужен Эрланг. Его главное преимущество — это параллельные процессы, как раз то, что не играет никакой роли в обработке униформных огромных объемов данных. Действительная арифметика там отстой, векторизации никакой нет, структуры данных типа таблиц не поддерживаются. Т.е. торможение во всем, а выгоды нет.

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


можно насчет плавающей точки поподробнее рассказать или указать где почитать? а то планирую кое какой софт выдать сравнительную версию на ерланг, но там плавающая точка достаточно важна (точнее важна до 3-5 знака после запятой в результате, но без потерь в получении этого результата в ходе мат операций)

Заранее спасибо.
... << RSDN@Home 1.2.0 alpha rev. 786>>
Я не умею быть злым, и не хочу быть добрым.
Re[6]: Ищу программирующих на Эрланге
От: Alex EXO http://aleksandr-zubarev.moikrug.ru/
Дата: 07.01.08 15:40
Оценка:
Здравствуйте, BulatZiganshin, Вы писали:
BZ>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца

А вдруг он уже устал от города?
Я вот устал... пару лет назад перебрался жить в лес. (Правда северный и прохладный — не люблю жару...)
Re[7]: Ищу программирующих на Эрланге
От: Курилка Россия http://kirya.narod.ru/
Дата: 11.01.08 10:28
Оценка:
Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, BulatZiganshin, Вы писали:

BZ>>а ты сможешь ему обеспечить привычную по мегаполису среду существования? я не просто так спрашиваю, дело в том, что учёные проводили эксперименты и выяснили, что выходцы из крупных городов в отсуствии смога гибнут через 2-3 месяца

AE>А вдруг он уже устал от города?

AE>Я вот устал... пару лет назад перебрался жить в лес. (Правда северный и прохладный — не люблю жару...)

Я вот тоже думаю...
Правда может не совсем в лес, но от смога уже есть некоторая усталость — думаю, нужно ли оно мне?
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.