Разработка ПО

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

Лайки собраны, поэтому наступает момент расплаты для меня. 

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

Я постараюсь ее реализовать, протестировать в бектрейдере, оптимизировать параметры и запустить в лайв.

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

Весь исходный код будет выложен в следующий постах, можно подписаться.

В этой статьи я опишу 3 варианта создания роботов.

На самом деле вариантов очень много, тут опишу только свой опыт. 

OsEngine

плюсы:

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

минусы:

Тяжело для новичков. 

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

Открыл, понажимал кнопочки, повспоминал C# и понял, что я не готов опять программировать на C#. Скорее всего это какие-то флешбеки из института. Но мне просто не нравится этот язык программирований. 

Заниматься тем, что вам не нравится это плохо…

TradingView + Wonderbit

Как это работает смотрим пост №2. 

плюсы:

очень просто написать и протестировать стратегию.

минусы: 

очень сложно запустить 10+ роботов. (из опыта)

( Читать дальше )

    Чистая архитектура — продолжение беседы с легендарным дядюшкой Бобом о взглядах на искусство разработки программного обеспечения.  

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

 

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

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

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

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

 


 Мы наблюдаем совершенно обыкновенную картину, где с переходом к новой версии (1 — 8) увеличивается число сотрудников участвующих в разработке и обслуживании системы. Теперь взглянем на график продуктивности сотрудников



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

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

В следующих разделах книги идет разговор о парадигмах программирования. Автор делает обзор на три из них:

• структурное 

• объектно-ориентированное 

• функциональное

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

Фактически последние полвека мы учились тому, как не надо делать

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

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

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

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

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

К сожалению (а может и к счастью) в книге приводится множество отсылок к технологиям “древнего” программирования, когда в качестве носителей еще использовали перфокарты. Это интересно читать с исторической точки зрения, но если вы хотите черпать новую информацию из книги, эти абзацы можно смело пропускать.

После обсуждения принципов SOLID книга набирает обороты в стороны абстракции, и я не могу сказать, что вынес пользу из прочтения “средних” глав книги — видимо снова проблема в опыте. Такой информационный перегруз мне еще не по зубам.

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

Это такие мелочи, которые пока нас не заботят. Мы решим этот вопрос позже

 

 

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

 

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

 

Однажды мне нужно было отрисовать пару графиков в консольной программе, написанной на С++. Можно было решить эту проблему двумя способами:

1. Сохранить график в файле и нарисовать его в экселе или другой софтине, м.б. даже в онлайн рисовалке
2. Рисовать график прямиком из программы

Первый способ мне не подходил, так как я проводил тестирование алгоритмов, и лишней возней с копированием данных заниматься не хотелось. Второй способ имеет множество решений, но увы я не нашел быстрого решения, чтобы библиотека для рисования не требовала целую кучу зависимостей. Обычно библиотеки для рисования из С++ программы хотят OpenCV или питон с матлабом. Еще как вариант я знаю SFML и ImGUI. Вопрос — нафига столько всего нужно для обычного графика, если по сути нужен OpenGL и все. Решил исправить эту проблему и набросал header-only С++ библиотеку, которая работает в отдельном потоке и способна рисовать графики зависимостей X от Y и тепловые карты. Из зависимостей библиотека требует FreeGLUT.

( Читать дальше )

Ответ на пост smart-lab.ru/blog/340718.php о сотрудничестве.

Добрый день Алексей.
Почему комментарии отключили?

Человек который будет искать клиентов, и договариваться
Будет владельцем бизнес-процесса.
И сам будет платить программистам от 20- до 45%

Это ясно видно по рынку 1с франчайзи .
Откуда взяты эти 15%?
Если найти клиента для около-рынка это минимум половина работы.

И то там 45% потому что клиенты лично видят в лицо программиста на проектах.
И могут с ним договорится при длинных контрактах.

Около-рынок в основном разовые клиенты.
Постоянных из них, по понятным причинам, становится гораздо меньше чем в 1с

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

• Изменен внешний вид платформы
• Изменено главное меню
• Исправлены ошибки в корреляторе
• Изменено отображение баров для работы на черном фоне.
• Исправлено множество багов в различных окнах.

Скриншоты:
 

 

 

 
В ближайшее время также планируется сделать сохранение профилей.
Глобально, в начале следующего года выйдет несколько новых инструментов для анализа.
Получить тестовый доступ к последней версии: [email protected]