Есть набор различных проектов. В которых есть расчетная часть и интеграционная часть. Расчетную часть пишут математики, интеграционную пишут программисты. Математикам удобнее всего питон. Ибо там куча либ из коробки на все случаи жизни, причем весьма шустро работающих, так как под капотом плюсы, а то и вообще CUDA и гоняется все на видеокартах.
Код математиков — это просто полный капец. Сплошной копипаст, хрен пойми как названные переменные, зачастую глобальные, вся логика в одной функции на 5000 строк и тому подобные прелести, и к этому еще многопоточность прикрутили.
Вопрос — как этот код использовать в реальном проекте? Собственно скорость кода вполне устраивает, вот только в таком коде кроме математиков никто разобраться не может, да и они сами после определенной сложности начинают делать кучу багов, и у них после определенного момента скорость разработки идет уже весьма низкая за счет ошибок, в том числе и ошибок типизации.
Какие вижу варианты:
1) Переписывать этот код. Причем на другой язык, чтоб статическая типизация была, покрывать тестами и т.д. Но получается двойная обезьянья работа — логика математиков весьма нетривиальна внутри, переписывать не быстро, разобраться в этом капеце и рефакторить весьма непросто, и в процессе переписывания хочется застрелиться. И одновременно с переписыванием нужно долго еще править баги, которые возникают в результате переписывания. Соответственно удовольствия от этого никакого, и у сотрудников сразу появляется желание к чертям менять работу и не заниматься этой хренью. Плюс нужно умножать сроки на время переписывания, причем коэффициент будет около четырех, то, что написали за месяц, переписываться будет 4 месяца.
2) Работать с этим кодом как с черным ящиком. Зафиксировать вход и выход. И вызывать этот питон через командную строку, а входные данные, если они большие, через файлы. Собственно пока так и сделал, ибо нужно все быстро показывать заказчику, а математики постоянно там логику черти как правят, причем еще и у них требования меняются. Но выглядит костыльно до ужаса, хоть и работает.
3) Оформлять питон код как сервис, упаковывать в докер контейнер, гонять в kubernetes, как все остальное приложение. Вроде выглядит более менее здраво и с минимум костылей, всю внешнюю обвязку в библиотеки. Возможно с большим скрипом проталкивать code reviev (почему с большим — математики это другое подразделение со своим начальником, а ревьюить их нужно со стороны программистов, по хорошему там нужно git flow попробовать заюзать вообще, но это малореально провести — это другой отдел). У программистов есть люди с хорошим уровнем именно питона, причем умеющие на нем писать. Вот только проблема — на питон они не вернутся, ибо язык не нравится, любят статическую типизацию. Соответсвенно непонятно, кого напрягать писать сервисную обвязку? Если математиков, то они нормально не напишут. Если программистов — есть риск что те, кому будет поручена такая задача, уволятся к чертям. Нанимать тех, кто на это подпишется?
4) Другой вариант.
Сам пока склоняюсь к третьему, но пока использую второй.
Но в идеале бы хотел, чтоб математики сразу писали на статически типизированном языке и писали нормально. Они на статически типизированном языке кстати пишут несколько получше, но на начальном этапе медленнее. После определенного этапа они даже на статически типизированном языке сами пишут быстрее. Правда для них библиотеки нужно писать и тому подобное. Вариант этот пробовали, кстати, и он работает удовлетворительно. Проблема в том, что без внимания биг босса все скатывается в хаос, а биг босс с этим хаосом несколько подустал бороться, да и у него начали возникать сомнения в том, что стоит бороться с этим зоопарком языков. Собственно понятно, что серебряной пули нет, во всех вариантах есть свои сильные и слабые стороны и нужно найти какой то компромисс.
Соответственно вопрос — какой из вариантов будет наименьшим злом? Третий?
Здравствуйте, Слава, Вы писали:
С>Подсунуть математикам Скалу, либо вообще Chapel, и посмотреть, что получится.
Они примерно отсюда то в питон то и свалили . Ибо на питоне больше интересующих их либ.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Слава, Вы писали:
С>>Подсунуть математикам Скалу, либо вообще Chapel, и посмотреть, что получится. E>Они примерно отсюда то в питон то и свалили . Ибо на питоне больше интересующих их либ.
Если честно, то я бы их просто уволил. Такой код — это открытая заявка: "Меня Вы теперь хер уволите, т.к. кроме меня тут ни кто разобраться не может, я не заменим" За это увольнять надо. Тут был на кывте случай: один писал кодек, что ли, вот он так его и написал, что кроме него в нем ни кто не сможет быстро разобраться. Естественно его сразу уволили. А так да, если с расчетом на будущее, то переписывать.
Я не пробовал, но в таких ситуациях мне всегда казалось, что хорошо будет работать парное программирование. Ну не обязательно прям парное, но суть в том, что с математиком работает человек, который хорошо программирует и в то же время имеет достаточно хорошее математическое образование, чтобы математик ему мог передавать то, что надо сделать. Собственно математик отвечает за математику, а программист пишет нормальный код.
Здравствуйте, elmal, Вы писали:
E>Есть набор различных проектов. В которых есть расчетная часть и интеграционная часть. Расчетную часть пишут математики, интеграционную пишут программисты. Математикам удобнее всего питон. Ибо там куча либ из коробки на все случаи жизни, причем весьма шустро работающих, так как под капотом плюсы, а то и вообще CUDA и гоняется все на видеокартах.
Такое ощущение, что мы работаем на одном проекте Только мы используем R вместо Python + недавно начали добавляться "нормальные" библиотеки на C# и C++.
По поводу №1 — на мой взгляд, такой подход не взлетит. Во-первых, в случае часто меняющихся требований, переписывание кода после прототипирования будет неэффективным. Во-вторых, бизнес просто может не понять такой подход — ведь им будет казаться вот же уже есть нормальный код на Питоне, который работает именно так как надо. А теперь приходит какой-то ИТшник и говорит, что нужно все переделывать на "нормальном" языке — кто будет тестировать? как будут требования оформляться? ведь вся фишка такого подхода, что математики могут бысто давать результат, который с минимальными задержками будет попадать на прод (пускай и будет неоптимально работать). Кроме того даже если "математики" начнут писать код на "нормальном" языке — это может не решить ваших проблем. Ну, дадут они вам экзешник или либу написанную на C++. Под капотам там будет такой же г-код, куча сторонних зависимостей, опять же как это дело запускать и т.д.
Поэтому мне кажется, что здесь прежде всего важно договориться с "математиками" (и между "программистов") о правильном подходе к написанию таких моделей.
1. Интерфейсы входа и выхода. Это ключевое требование, на мой взгляд. Интерфейсы должны быть четко описаны, должна поддерживаться их версионность. Мне кажется, что даже передача входных / выходных данных через файлы может быть ОК, если описание дано не на уровне CSV файл с такими-то именами колонок, а хотя бы имена, типы, диапазоны допустимых значений, поддержка пустых значений и т.д.
2. Развертывание модели и зависимостей. Каким образом код, который написали математики будет попадать на дев и прод сервера? Как будут управляться зависимости? Что, например, будет, если одна группа математиков напишет модель, которая использует библиотеку А версии 1, а другая — модель, которая использует ту же библиотеку, но версии 2. Как я уже писал мы в основном используем R и управляем зависимостями через пакеты. Т.е. каждая модель это свой R пакет + все зависимости этой модели это тоже R пакеты. Далее, каждая группа математиков дает ИТ свой набот R пакетов, которые входят в эту модель, упакованные в MSI. Потом эту MSI можно деплоить на любом сервене, устанавливать их параллельно, т.к. все пакеты из модели попадут в свою отдельную папку и не будут мешаться. В нашем случае, единственное ограничение — это то, что все должны использовать одну версию R. Для нас такой подход работает нормально, при желании можно даже hot deployment делать. Наверное, здесть также хорошо подошел бы docker.
3. Отсутствие side effects и external dependencies. Естественно, что модели должны получать все данные через входной интерфейс и не лезть ни в какие внешние базы данных, не должно быть кросс-зависимостей, работа одной модели не должна затрагивать другие модели и т.д.
4. Атомарность работы модели. Возможно это спорный пункт. Но с моей т.з. каждая модель должна выполнять свой ограниченный unit of work и не должна работать в батч режиме. Т.е. например, если стоит задача распознания образов на изображении, то модель должна принимать на вход одно изображение и возвращать для него образы. А не принимать список изображений, дальше как-то парллелить их обработку и т.д. Все таки задача пакетной обработки / парллелизации, это больше относиться к сфере ИТ. Хотя конечно здесь есть нюансы.
5. Остальные SLAs — ожидаемое время работы модели, возможность красиво прервать работу модели, логирование работы модели (был у нас один кадр, который писал модели, работающие часами и при этом упорно не дающие информацию о прогрессе работы), поведение в случае ошибки. Последнее особенно важно. Понятно, что падение модели не должно приводить к краху сервису. Также оно не должно затрагивать модели работающие в параллели. Также должна быть возможность легко перезапустить упавшую модель с такими же входными данными. Ну, и самое главное, чтобы математики могли разобраться в причинах ошибки — нужно предусмотреть автоматическое логирование входных данных + колл стэк ошибки + сохранения лога работы модели. В этом случае, ИТ сможет легко отправить эти данные математикам и у тех будет вся информация, чтобы разобраться с проблемой локально.
По сути, при соблюдение этих правил каждая модель будет представлять своего рода микросервис. Но при этом на мой взгляд будет не так уж важно, как именно будет запскаться модель. Например, мы запускаем наши модели не через консоль, а через R.NET библиотеку (думаю, что для Питона тоже есть подобные библиотеки), которая позволяет запускать R код и работать с R структурами прямо из .NET кода. Но даже если бы мы запускали через консоль, то я не думаю, что мы бы сильно потеряли (может быть за исключением тонкой обработки ошибок и быстродействия). кстати, мы также рассмтривали возможность автоматически превращать R код в Rest API сервисы (https://www.rplumber.io/), но нам показалось это переусложнением. Возможно для Питона есть что-то подобное.
Теперь если говорить о подходе №3 — то он конечно выглядит красиво, но из моей практики — математики — это не те люди, которые будут писать сервисы/АПИ и возиться с докером. Им важно иметь возможноть писать код быстро, легко и что самое главное запускать его в интерактивном режиме локально. Языки типа Python/R дают прекрасную возможность для этого. Поэтому скорей всего возиться с сервисами и деплойментов придется уже вам. Но в случае если модели, которые пишут математики будут соответстовать пунктам описаным выше, то и подход №2 будет вполне работоспособен.
Здравствуйте, elmal, Вы писали:
E>Соответственно вопрос — какой из вариантов будет наименьшим злом? Третий?
Все три варианта неудачные так как ты исходишь из нескольких неверных посылов и желания все переделать. Во-первых, математики могут писать хороший код, во-вторых,на Python можно писать серьезный и элегантный код, в-третьих, тотальное переписывание приведет к еще большему количеству ошибок так как параллельно ожидать новый функционал никто не перестанет. И Главный Вопрос тут будет не что делать, а на что у тебя хватает полномочий?
В идеале вам нужно делать смешанные команды и учить математиков писать хороший код на Python, организовать для них лекции. У вас, надеюсь, есть кто-то хорошо знающий Python и при этом способный не просто мычать говоря на публику? Вам надо нормально поставить процесс разработки с CI, добавить линтеры которые будут рубить совсем уж откровенное УГ еще на этапе коммита, в процессе ревью указывать на ошибки и показывать правильные решения, начать активно использовать аннотации типов и интеграционные тесты. Это долгий процесс, но именно он принесет реальные плоды.
E>Код математиков — это просто полный капец. Сплошной копипаст, хрен пойми как названные переменные, зачастую глобальные, вся логика в одной функции на 5000 строк и тому подобные прелести, и к этому еще многопоточность прикрутили.
E>Вопрос — как этот код использовать в реальном проекте? Собственно скорость кода вполне устраивает, вот только в таком коде кроме математиков никто разобраться не может, да и они сами после определенной сложности начинают делать кучу багов, и у них после определенного момента скорость разработки идет уже весьма низкая за счет ошибок, в том числе и ошибок типизации.
E>Какие вижу варианты: E>1) Переписывать этот код. Причем на другой язык, чтоб статическая типизация была, покрывать тестами и т.д. Но получается двойная обезьянья работа — логика математиков весьма нетривиальна внутри, переписывать не быстро, разобраться в этом капеце и рефакторить весьма непросто, и в процессе переписывания хочется застрелиться. И одновременно с переписыванием нужно долго еще править баги, которые возникают в результате переписывания. Соответственно удовольствия от этого никакого, и у сотрудников сразу появляется желание к чертям менять работу и не заниматься этой хренью. Плюс нужно умножать сроки на время переписывания, причем коэффициент будет около четырех, то, что написали за месяц, переписываться будет 4 месяца.
Разработка алгоритма и кодирование — вообще говоря разные отдельные работы, каждую из которых эффективнее выполнять своим узким специалистом. Пусть математики разрабатывают алгоритм на чём им удобно (питон, матлаб, эксель), и отдают программистам кодировать на C с соблюдением стандартов кодирования. А если математиков ещё и приучить иногда прослеживать закодированный не ими алгоритм в пошаговом отладчике...
Здравствуйте, elmal, Вы писали:
E>1) Переписывать этот код. Причем на другой язык, чтоб статическая типизация была, покрывать тестами и т.д.
давно не видел говнокода на статических языках?
имхо, крышей не надо ехать в своём фанатизме.
E>2) Работать с этим кодом как с черным ящиком. Зафиксировать вход и выход. И вызывать этот питон через командную строку, а входные данные, если они большие, через файлы.
а чего бы не встроить в свой код? по крайней мере без извращений с командной строкой.
E>3) Оформлять питон код как сервис, упаковывать в докер контейнер, гонять в kubernetes, как все остальное приложение.
вполне вариант.
E>У программистов есть люди с хорошим уровнем именно питона, причем умеющие на нем писать. Вот только проблема — на питон они не вернутся, ибо язык не нравится, любят статическую типизацию.
зачем нужны люди, которые не любят делать работу?
там обвязки-то всего ничего будет.
E>4) Другой вариант.
Здравствуйте, neFormal, Вы писали:
F>а чего бы не встроить в свой код? по крайней мере без извращений с командной строкой.
А каким образом это сделать? Основная платформа — Java. Пробовал встраивать через graalvm. Пока оказалось сыро, сами разработчики говорят, что пока экспериментально, хоть и обещают что через несколько месяцев будет что работать. Текущая проблема — pip модули не поддерживаются.
F>зачем нужны люди, которые не любят делать работу? F>там обвязки-то всего ничего будет.
Ну да, логично. Есть прекрасный разработчик, который прекрасно работает на других языках. И который пришел как раз к нам, так как его взяли с python бекграундом без знания Java. Ибо язык достал. Конечно же логично, что в благодарность за его работу нужно его пересадить с нормального проекта на python. А если откажется — уволить . При этом если бы человек скрывал, что знает язык, который ему не нравится — к нему бы никаких претензий не было.
E>>4) Другой вариант. F>учить.
Обучение происходит крайне медленно. Вот реально, человек или знает нормально математику и хоть как то программирует, при этом учится именно программированию крайне медленно. Или нормально программирует, но руки заточены не под математику.
Здравствуйте, kaa.python, Вы писали:
KP>Все три варианта неудачные так как ты исходишь из нескольких неверных посылов и желания все переделать. Во-первых, математики могут писать хороший код, во-вторых,на Python можно писать серьезный и элегантный код, в-третьих, тотальное переписывание приведет к еще большему количеству ошибок так как параллельно ожидать новый функционал никто не перестанет. И Главный Вопрос тут будет не что делать, а на что у тебя хватает полномочий?
Полномочий в виде консультанта хватит на все. И нормальное решение по конкретному проекту так или иначе будет принято. При условии, что сроки не полетят к черту. И самое основное — именно переделывать то как раз не хочется.
KP>В идеале вам нужно делать смешанные команды и учить математиков писать хороший код на Python, организовать для них лекции. У вас, надеюсь, есть кто-то хорошо знающий Python и при этом способный не просто мычать говоря на публику?
Это все есть и попытки в этом направлении ведутся. Попытки научить математиков писать хотя бы приемлемый код так или иначе проваливаются. Причем с разными математиками. Нет, они учатся, но учатся недостаточно быстро. И как только перестаешь следить — код слетает в полный кошмар. Проблема еще в том, что математики — это другой отдел. За ними можно следить когда знаешь, что они занимаются проектом. Но когда они что то пилят полгода, как прототип, причем зачастую об этом не знаешь вообще, при этом не коммитят никуда, где их творчество видно, зачастую вообще если предоставлены сами себе git не пользуются, фигачат прям на сервере удаленно в текстовом редакторе без среды разработки. Когда через полгода уже видишь это творчество за которым не следили, хочется застрелиться. Естественно потом начинаются административные принуждения к git, естественно начинается борьба за качество кода, лекции и т.д. Но это все начинается тогда, когда уже поздно, код до такого состояния доводить нельзя. Так или иначе даже питоновкий код разгребется по минимально приемлемого. Но на новом проекте, когда они будут предоставлены сами себе, все скорее всего снова повторится. Там собственно ужас ужас ужас и появился в связи с тем, что ослаб контроль, математикам разрешили писать на чем им угодно. А для того, чтоб качественно писать на динамических языках, квалификация должна быть больше, чем если б писали на статических.
Здравствуйте, Osaka, Вы писали:
O>Разработка алгоритма и кодирование — вообще говоря разные отдельные работы, каждую из которых эффективнее выполнять своим узким специалистом. Пусть математики разрабатывают алгоритм на чём им удобно (питон, матлаб, эксель), и отдают программистам кодировать на C с соблюдением стандартов кодирования. А если математиков ещё и приучить иногда прослеживать закодированный не ими алгоритм в пошаговом отладчике...
Это как раз и есть вариант переписывания, то есть выполнение тройной а то и четверной работы.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Osaka, Вы писали:
O>>Разработка алгоритма и кодирование — вообще говоря разные отдельные работы, каждую из которых эффективнее выполнять своим узким специалистом. Пусть математики разрабатывают алгоритм на чём им удобно (питон, матлаб, эксель), и отдают программистам кодировать на C с соблюдением стандартов кодирования. А если математиков ещё и приучить иногда прослеживать закодированный не ими алгоритм в пошаговом отладчике... E>Это как раз и есть вариант переписывания, то есть выполнение тройной а то и четверной работы.
Если аналитик пишет ТЗ в ворде, и отдаёт его кодить, — это же не переписывание? Вот и творения математиков использовать как своего рода ТЗ для кодеров.
Здравствуйте, elmal, Вы писали:
E>Есть набор различных проектов. В которых есть расчетная часть и интеграционная часть. Расчетную часть пишут математики, интеграционную пишут программисты. Математикам удобнее всего питон. Ибо там куча либ из коробки на все случаи жизни, причем весьма шустро работающих, так как под капотом плюсы, а то и вообще CUDA и гоняется все на видеокартах.
У нас есть код на Питоне, занимающийся расчётами электроцепей. Написан очень красиво и с комментариями даже, с использованием Pyrex и оптимизацией. Но поддерживать стало сложно — оптимизации не очень сочитаются с Jupyter и не все математики их понимают.
В итоге новые модули начали писать на Julia — всем понравилось. Язык очень математически-ориентированный и быстрый за счёт JIT-компиляции. Все нужные библиотеки тоже там есть, включая и GPGPU и нейронки.
Здравствуйте, Cyberax, Вы писали:
C>В итоге новые модули начали писать на Julia — всем понравилось. Язык очень математически-ориентированный и быстрый за счёт JIT-компиляции. Все нужные библиотеки тоже там есть, включая и GPGPU и нейронки.
Вопрос тогда переформулирую. Есть основной язык, в основном используемый для интеграции, взаимодействия с внешними сервисами, базами данных и т.д. Это Java совместимый язык, тут без вариантов.
Есть идеальный абстрактный язык для математиков. Который, гад, в JVM не компилится, по крайней мере вместе с библиотеками, чтобы подрубить как jar зависимость и не париться.
Так вот, как этот язык включать в общую систему? Оформлять как микросервис и взаимодействовать с ним через http(s)? При этом силами программистов написать сервисную обвязку. Вариант лучше есть?
ИМХО вариант получше будет, когда graalpython будет более работоспособный. Потому предполагаю что как только они допилят, можно будет мигрировать в этом направлении и тупо включать питоновскую стороннюю логику как jar. Вот только зх сколько ждать работоспособности, проект к этому моменту может закончиться.
Здравствуйте, elmal, Вы писали:
C>>В итоге новые модули начали писать на Julia — всем понравилось. Язык очень математически-ориентированный и быстрый за счёт JIT-компиляции. Все нужные библиотеки тоже там есть, включая и GPGPU и нейронки. E>Вопрос тогда переформулирую. Есть основной язык, в основном используемый для интеграции, взаимодействия с внешними сервисами, базами данных и т.д. Это Java совместимый язык, тут без вариантов.
Ок.
E>Есть идеальный абстрактный язык для математиков. Который, гад, в JVM не компилится, по крайней мере вместе с библиотеками, чтобы подрубить как jar зависимость и не париться.
Для Julia можно сделать интероп ( http://juliainterop.github.io/JavaCall.jl/ ), но лучше не надо, да.
E>Так вот, как этот язык включать в общую систему? Оформлять как микросервис и взаимодействовать с ним через http(s)? При этом силами программистов написать сервисную обвязку. Вариант лучше есть?
Конкретно у нас это делается в виде задач, которые запускаются на вычислительный кластер, получая входные данные через файлы и/или stdin. Обвязка (на Ruby, к сожалению) просто вытягивает из БД всё нужное, формирует JSON, запускает задачу и ждёт ответа.
Таким образом, вычисления на Julia, которые местами ещё используют падучую жуть типа CUDA и OpenCL, надёжно изолированы от обычной обвязки. Опять же, разработка и отладка в Jupyter получается тоже очень удобной — так как все входные данные берутся из простых файлов и не нужно заниматься установкой всяких БД.
Вариант с микросервисом тоже вполне нормален, в Julia он встроен в стандартную библиотеку.
Здравствуйте, elmal, Вы писали:
E>Это как раз и есть вариант переписывания, то есть выполнение тройной а то и четверной работы.
Вот тут совсем не согласен, это совсем разные виды работ. От математиков работающую модель и документацию, а от программистов код, оптимизацию и интеграцию. Это абсолютно нормальный вариант.
Здравствуйте, elmal, Вы писали:
E>Какие вижу варианты: E>1) Переписывать этот код. Причем на другой язык, чтоб статическая типизация была, покрывать тестами и т.д. Но получается двойная обезьянья работа — логика математиков весьма нетривиальна внутри, переписывать не быстро, разобраться в этом капеце и рефакторить весьма непросто, и в процессе переписывания хочется застрелиться. И одновременно с переписыванием нужно долго еще править баги, которые возникают в результате переписывания. Соответственно удовольствия от этого никакого, и у сотрудников сразу появляется желание к чертям менять работу и не заниматься этой хренью. Плюс нужно умножать сроки на время переписывания, причем коэффициент будет около четырех, то, что написали за месяц, переписываться будет 4 месяца.
Переписывать — это плохой вариант.
а) "Математический" код сложен сам по себе, и даже после переписывания его не сделать идеальным. Статически типизированный язык может еще больше усложнить переписывание, а плюсов не дать никаких.
б) Существующие библиотеки позволяют реализовывать алгоритмы на более высоком уровне абстракции. Питон, думаю, выбран как раз по причине наличия удобных математических библиотек. Код на другом языке может оказаться еще сложнее (при отсутствии библиотек).
Возможно, хорошо помогло бы краткое текстовое описание алгоритмов (на будущее, для поддержки, а не для переписывания).
E>2) Работать с этим кодом как с черным ящиком. Зафиксировать вход и выход. И вызывать этот питон через командную строку, а входные данные, если они большие, через файлы. Собственно пока так и сделал, ибо нужно все быстро показывать заказчику, а математики постоянно там логику черти как правят, причем еще и у них требования меняются. Но выглядит костыльно до ужаса, хоть и работает.
а) Именно так и надо — считать его черных ящиком, ведь код разрабатывает другая команда. Иначе теряется смысл разбиения на команды.
б) Обязательно нужно договориться об интерфейсе обмена данными и придерживаться его. Наверное, даже стоит подстроиться под математиков, так как разработка ведется "от них".
Например, договориться, что каждый отдельный алгоритм на питон размещать в своем отдельном скрипте. Чтобы было удобно вызывать его из командной строки.
В дальнейшем, совершенствовать договоренности — выделять каждый алгоритм в отдельные функции/модули и т.п.
Передача данных через файлы — норм, если названия файлов указываются в параметрах к скрипта.
в) В основной системе написать обвязку для вызова таких математических алгоритмов (выделить в отдельный классе/модуле/слой). Менять по мере изменения договоренностей о вызове алгоритмов. Написать тесты, которые будут тестировать этот черный ящик. Как минимум тестировать соблюдение договоренностей по вызову.
E>3) Оформлять питон код как сервис, упаковывать в докер контейнер, гонять в kubernetes, как все остальное приложение. Вроде выглядит более менее здраво и с минимум костылей, всю внешнюю обвязку в библиотеки. Возможно с большим скрипом проталкивать code reviev (почему с большим — математики это другое подразделение со своим начальником, а ревьюить их нужно со стороны программистов, по хорошему там нужно git flow попробовать заюзать вообще, но это малореально провести — это другой отдел). У программистов есть люди с хорошим уровнем именно питона, причем умеющие на нем писать. Вот только проблема — на питон они не вернутся, ибо язык не нравится, любят статическую типизацию. Соответсвенно непонятно, кого напрягать писать сервисную обвязку? Если математиков, то они нормально не напишут. Если программистов — есть риск что те, кому будет поручена такая задача, уволятся к чертям. Нанимать тех, кто на это подпишется?
а) Выделять в докер-контейнер нужно (очень желательно). В питоне много зависимостей в библиотеках, разбирать несовместимости при деплое никому не хочется. Пусть математики используют, что хотят. Для создания (и поддержки) контейнера привлечь сотрудника, который занимается деплоем математического кода сейчас. Он и сам будет рад, когда деплой сильно упроститься.
б) Если выполнить нормально второй пункт (наладить доступ к черному ящику), то можно будет сделать дополнительную надстройку для вызова черного ящика через http (API на flask делается очень просто), очередь сообщений (MQ), сокеты и т.п.
в) Обо всех изменениях надо разговаривать с начальником другого отдела (с подключением их программистов). Для начала продавить интерфейс обмена данными между системам, согласовать такую важную штуку с боссом. После этого они сами захотят git для версионности кода (а может и тесты)
г) Сделать сервисную обвязку — напрячь программистов. Судя по описанию ее там совсем немного. Задача обвязки — перевести вызов питон кода в что-то доступное для обоих языков — http, сообения, файлы и т.п. Но заранее договориться о едином стандарте вызова питон кода для всех проектов (через скрипты, через функции), тогда обвязку не придется переделывать для каждого проекта.
E>4) Другой вариант.
Делать второй вариант, затем третий.
E>Но в идеале бы хотел, чтоб математики сразу писали на статически типизированном языке и писали нормально. Они на статически типизированном языке кстати пишут несколько получше, но на начальном этапе медленнее. После определенного этапа они даже на статически типизированном языке сами пишут быстрее. Правда для них библиотеки нужно писать и тому подобное. Вариант этот пробовали, кстати, и он работает удовлетворительно. Проблема в том, что без внимания биг босса все скатывается в хаос, а биг босс с этим хаосом несколько подустал бороться, да и у него начали возникать сомнения в том, что стоит бороться с этим зоопарком языков. Собственно понятно, что серебряной пули нет, во всех вариантах есть свои сильные и слабые стороны и нужно найти какой то компромисс.
По-моему, Ваше желание переписать код на статически типизированном языке исходит из желания держать все под контролем. Не надо этого делать, обговорите интерфейсы, соблюдайте их, требуйте соблюдения (через бигбосса).
Улучшать свой код должен другой отдел. У них свой начальник. По вопросам улучшения кода (ревью, обучение) — к нему.
Здравствуйте, Буравчик, Вы писали:
Б>По-моему, Ваше желание переписать код на статически типизированном языке исходит из желания держать все под контролем. Не надо этого делать, обговорите интерфейсы, соблюдайте их, требуйте соблюдения (через бигбосса).
На самом деле там ситуация поинтереснее. На статически типизированном языке там в свое время был написан неплохой DSL. Который хорошо покрывает задачи предметной области и в результате код выглядит на порядок читабельнее. Там даже математикам это больше нравилось, чем то, что есть на питоне. Плюс там из коробки было легкое тестирование, можно было написать тесты вообще без проблем. Плюс там была сделана дополнительная обвязка и куча всего автоматизировано. Но блин не было кучи других библиотек. Соответственно если оставлять все на питоне, то нужно снова самостоятельно, уже на питоне, переписывать тот DSL. Ибо этот DSL в свое время и был создан чтобы то, что писали математики не выглядело как полный ужас, было как можно все ближе именно к математическому синтаксису. Плюс поднимать и развивать питон инфраструктуру, писать либы, заточенные под предметную область.
Соответственно питон тоже нельзя оставлять как есть. Нормальные заточенные именно под наши задачи библиотеки математики не напишут никогда в жизни. И если развивать именно питоновские либы, это нужно сажать на эти либы разработчиков. Причем нужно сажать достаточно квалифицированных, а они заняты на других проектах.
Здравствуйте, elmal, Вы писали:
F>>а чего бы не встроить в свой код? по крайней мере без извращений с командной строкой. E>А каким образом это сделать? Основная платформа — Java. Пробовал встраивать через graalvm. Пока оказалось сыро, сами разработчики говорят, что пока экспериментально, хоть и обещают что через несколько месяцев будет что работать. Текущая проблема — pip модули не поддерживаются.
я бы попробовал https://github.com/ninia/jep
или что-нить ещё из этого списка: https://wiki.python.org/moin/IntegratingPythonWithOtherLanguages
F>>зачем нужны люди, которые не любят делать работу? F>>там обвязки-то всего ничего будет. E>Ну да, логично. Есть прекрасный разработчик, который прекрасно работает на других языках. И который пришел как раз к нам, так как его взяли с python бекграундом без знания Java. Ибо язык достал. Конечно же логично, что в благодарность за его работу нужно его пересадить с нормального проекта на python. А если откажется — уволить . При этом если бы человек скрывал, что знает язык, который ему не нравится — к нему бы никаких претензий не было.
с питона ушёл в жяву? не, ну этого надо уволить. дважды.
мне очень сложно понять мотивацию этого человека. и очень не верится, что он прекрасно работает. не встречал таких
но пофиг. этот человек может оценить трудозатраты по созданию сервисной обвязки.
сложно, конечно, сказать, что вы там под этим подразумеваете... но в случае rest там три файла: точка входа, роутинг и пример хендлера.
дальше даже математики смогут добавить доп. рычаги
E>>>4) Другой вариант. F>>учить. E>Обучение происходит крайне медленно. Вот реально, человек или знает нормально математику и хоть как то программирует, при этом учится именно программированию крайне медленно. Или нормально программирует, но руки заточены не под математику.
это да. один из самых медленных путей. тем более, у вас разные отделы с разным руководством.
но может повезёт
. Ибо на питоне больше интересующих их либ.
