По коду всё более грустно)) Пишу исключительно из своих представлений о хорошем коде, захотел ли я использовать такой код в своем приложение -- скорее нет.
1. Непонятно, какая целевая версия питона используется, судя по List, Tuple -- меньше 3.12. 2. Большие по объему модули и использование функционального подхода, а не ООП сильно затрудняют чтение. 3. Неконсистентное использование аннотаций типов, то есть, то нет. 4. Неиспользование static typechecking, хотя бы ruff. 5. Большое количество констант и настроек прямо в коде. Их бы или собрать всех вместе в constants.py или вынести в .yaml файл (это было бы намного удобнее для использования). 6. Отсутствие тестов хотя бы для расчетных задач. Как вообще без этого можно элементарно доверять коду? А если банальная опечатка, или + вместо -, как уже написали выше? 7. Большое количество текстовых сообщений везде по коду, причем в виде printf(). Тут как минимум напрашивается флаг(и) в настройках, который позволяет отключать группы сообщений.
Ну и с практической (и прагматической) точки зрения: для российских пользователей на текущий момент гораздо более актуальны данные по активам на MOEX, чем на NASDAQ или NYSE. Ибо, как показывает опыт последних лет, политика бывает очень переменчива, а риски разумно диверсифицировать.
Красивый проект с визуальной точки зрения! Да, работа проделана очень большая, видно, сколько усилий вложено.
Теперь по существу, замечания и предложения. 1) Презентацию Вы сделали хорошо, но это работает, если Вы хотите продемонстрировать проект человеку, далекому от IT. Хабр -- профильное сообщество, то же самое и Github, поэтому...
2) На мой взгляд, надо определиться с целевой аудиторией поста, кому Вы рассказываете и что хотите рассказать. Это пост для разработчиков? Для дизайнеров? Для потенциальных работодателей? Для прославления себя любимого?
Если это пост про разработку, то хочется прочитать именно про разработку, почему выбрали те или иные инструменты и технологии, какие возникли проблемы по мере использования, как их решали.
Если пост для дизайнеров, то будет совсем другой подход и коленкор.
3) Если говорить о Github, то в README прежде всего хочется прочесть о фичах проекта и о том, как проект установить у себя (особенно если Вы хотите, чтобы другие люди в нем поучаствовали). А вот вся эта простыня со скриншотами там совершенно не нужна и даже вредна! У занятых людей нет времени, чтобы просматривать эту лабуду и они не будут это делать. Одного скриншота в начале README достаточно.
4) Что касается скриншотов и подробного описания возможностей, то их лучше оформить в виде документации к проекту и разместить на отдельной странице, а в README достаточно ссылки на эту документацию, или на пост на Хабре.
5) Собственно по развитию проекта дальше (если планируете его развивать). Вот этот фейерверк технологий, он прекрасен для презентации, но в реальном сопровождении это гемор. Все что может сломаться -- сломается! Зачем 3 базы данных в проекте? Зачем миллион зависимостей в requirements.txt? Лучше использовать меньше технологий и лучше протестировать их связи, тогда больше шансов, что через полгода при каком-нибудь обновлении ничего не сломается. Не говоря уже о том, что меньше зависимостей быстрее устанавливаются, занимают меньше места и жрут меньше ресурсов.
Для альфа-версии вообще всё отлично!
Задумка и реализация в целом интересные!
По коду всё более грустно)) Пишу исключительно из своих представлений о хорошем коде, захотел ли я использовать такой код в своем приложение -- скорее нет.
1. Непонятно, какая целевая версия питона используется, судя по List, Tuple -- меньше 3.12.
2. Большие по объему модули и использование функционального подхода, а не ООП сильно затрудняют чтение.
3. Неконсистентное использование аннотаций типов, то есть, то нет.
4. Неиспользование static typechecking, хотя бы ruff.
5. Большое количество констант и настроек прямо в коде. Их бы или собрать всех вместе в constants.py или вынести в .yaml файл (это было бы намного удобнее для использования).
6. Отсутствие тестов хотя бы для расчетных задач. Как вообще без этого можно элементарно доверять коду? А если банальная опечатка, или + вместо -, как уже написали выше?
7. Большое количество текстовых сообщений везде по коду, причем в виде printf(). Тут как минимум напрашивается флаг(и) в настройках, который позволяет отключать группы сообщений.
Ну и с практической (и прагматической) точки зрения: для российских пользователей на текущий момент гораздо более актуальны данные по активам на MOEX, чем на NASDAQ или NYSE. Ибо, как показывает опыт последних лет, политика бывает очень переменчива, а риски разумно диверсифицировать.
Рад за вас, что вы нашли инструмент, который закрывает ваши потребности.
Спасибо за статью!
Красивый проект с визуальной точки зрения! Да, работа проделана очень большая, видно, сколько усилий вложено.
Теперь по существу, замечания и предложения.
1) Презентацию Вы сделали хорошо, но это работает, если Вы хотите продемонстрировать проект человеку, далекому от IT. Хабр -- профильное сообщество, то же самое и Github, поэтому...
2) На мой взгляд, надо определиться с целевой аудиторией поста, кому Вы рассказываете и что хотите рассказать. Это пост для разработчиков? Для дизайнеров? Для потенциальных работодателей? Для прославления себя любимого?
Если это пост про разработку, то хочется прочитать именно про разработку, почему выбрали те или иные инструменты и технологии, какие возникли проблемы по мере использования, как их решали.
Если пост для дизайнеров, то будет совсем другой подход и коленкор.
3) Если говорить о Github, то в README прежде всего хочется прочесть о фичах проекта и о том, как проект установить у себя (особенно если Вы хотите, чтобы другие люди в нем поучаствовали).
А вот вся эта простыня со скриншотами там совершенно не нужна и даже вредна! У занятых людей нет времени, чтобы просматривать эту лабуду и они не будут это делать. Одного скриншота в начале README достаточно.
4) Что касается скриншотов и подробного описания возможностей, то их лучше оформить в виде документации к проекту и разместить на отдельной странице, а в README достаточно ссылки на эту документацию, или на пост на Хабре.
5) Собственно по развитию проекта дальше (если планируете его развивать). Вот этот фейерверк технологий, он прекрасен для презентации, но в реальном сопровождении это гемор. Все что может сломаться -- сломается! Зачем 3 базы данных в проекте? Зачем миллион зависимостей в requirements.txt? Лучше использовать меньше технологий и лучше протестировать их связи, тогда больше шансов, что через полгода при каком-нибудь обновлении ничего не сломается. Не говоря уже о том, что меньше зависимостей быстрее устанавливаются, занимают меньше места и жрут меньше ресурсов.
Удачи!
Познавательный и поучительный текст, спасибо!
Системный подход! Действительно, через какое-то время контекст забывается, а заметка позволяет быстро вспомнить суть, а не перечитывать документацию.
Отличная статья и хороший опыт! Желаю дальнейших успехов на поприще профессионального программирования!