Самое проблемное - объективно посчитать ROI, в т.ч. очищенный от других факторов. Я в живую таких примеров ни разу не видел, в вашей статье об этом тоже ни слова.
Идея не самая свежая, картинка на скриншоте - красивая... в остальном - "Не верю! (с) Станиславский
Не ясно как удалось с помощью формата "магазина" решить эту проблему. У каждого заказчика свой лимит на долю капасити команды? Или кто первый "накидал фич в корзину" "того и тапки"?
Нет универсальных метрик OKR, которые позволили бы сравнивать фичи с точки зрения ценности для бизнеса?
Сколько тестов вы написали для этой фичи? Покрытие выше 80%?" Этот вопрос скорее не про контроль, а про то, чтобы разработчики сами задумались: а как проверить, что это работает? А что будет, если завтра кто-то изменит этот код?
Зачем? Если автоматическая проверка легко встраивается в пайплайн CI/CD и систему контроля версий?
Когда последний раз вы рефакторили этот модуль? Он не стал сложнее за последний год?" Вопрос про технический долг. Он накапливается незаметно. Один раз не почистили, второй, третий. И вот уже модуль превратился в лабиринт, в котором страшно что-то менять.
А кто включил задачу на рефакторинг в бэклог и обозначил приоритет для команды разработки?
Если завтра ты уйдешь в отпуск, кто сможет поддержать этот код?" Вопрос про знание кодовой базы. Если код понятен только одному человеку, это риск для компании. Знания должны распределяться.
«Код понятен» и «знание кодовой базы» — это не одно и тоже. Ожидать, что разработчик будет «наизусть» знать кодовую базу среднего по размеру проекта как-то наивно даже.
Новичок придет через месяц. Как он поймет, что делает этот модуль? Где документация?" Вопрос про долгосрочность. Код живет годами. Люди, которые его писали, могут уйти. Но код останется. И кто-то должен его понять.
Зачем, если с документацией к коду уже неплохо справляются автоинструменты?
Пока статья больше из серии «Делай хорошо и будет хорошо». Ни слова о прибыли для собственников, дедлайнах, межличностных отношениях в коллективе, «перетягивания одеяла».. Всё красиво — как по книжкам, а по факту — поверхностный взгляд на чудесную организацию в идеальных условиях
Почему просто не взять готовые решения для бэктестов типа backtrader, Backtesting.py, не изобретать велосипед и не наступать на одни и те же грабли каждый раз (это про look-ahead bias). Тот же TA-lib для расчётов индикаторов? Зачем гнаться за скоростью, если HFT не является целью? Сомневаюсь, что на часовых свечах при ограниченном наборе инструментов подобные оптимизации имеют большое значение
Хорошая обзорная статья - всё сжато и по делу. Вот только без обработки исключений / ошибок, access / refresh токенов, ретрая, журналирования, расчета IO-метрик... до production ready всё равно ещё больше половины пути. Что удивительно - сценарий частый / проблема общая, каждый пишет свой велосипед, но так никто и не взялся за универсальный "комбайн"
Можно как-то остановить этот поток малоинформативных статей под эгидой АИС «Налог-3», единственной целью которых является раскрутка телеграм-канала автора?
shtolman , в коммерции с договорённостями "на словах" тот же результат не заставит себя долго ждать. В целом юристы, аналитики, тестировщики, UX/UI дизайнеры - не зря свой хлеб едят, если демпенгуете на рынке и хотите закрыть все вопросы своими руками - трезво оценивайте все риски.
Если для заказчика проект непрофильный, то наивно ожидать там необходимых компетенций, дельных ТЗ, готовности брать на себя ответственность за решения по проекту. Редко когда отношение команды заказчика к исполнителю в проекте выходит за рамки: "хочешь заработать? сам и работай!" — никто не бросит свои текущие дела / задачи ради ваших сроков / доходов))
Никогда не встречал дотошных ТЗ у госов)) Повсеместно полно воды и копипаст из нормативки или других контрактов. Ткните пальцем на zakupki.gov если не сложно))
Как при чём? Сидит человек CVE list трекает, а за что в "зоопарке" в первую очередь хвататься - не знает. Или с другой стороны - платят деньги человеку, а хорошо ли / плохо ли он свою работу выполняет - непонятно...))
Тут к слову даже обосновать необходимость такого человека со сканером в руках сподручнее))) Но если денех на ИБ нет, то вопросов нет конечно))
Годная статья, спасибо. Осталось отказаться от "велосипеда" и использовать готовые tenacity/stamina для retry, asyncio.Task.cancelling() для Graceful shutdown))
@thestratblog не совсем ясно — за чем OKR непосредственно командам? Обычно между командой и бизнесом есть владелец продукта и приоритезация задач, и конкретизация ожидаемых результатов для команды это его прямая обязанность, разве нет?
Табличка в Экселе, или не дай бог - файловая шара, это уже иная ИС, или пока ещё нет?)
Интересное сравнение, спасибо что поделились своими впечатлениями от участия в проекте
Самое проблемное - объективно посчитать ROI, в т.ч. очищенный от других факторов. Я в живую таких примеров ни разу не видел, в вашей статье об этом тоже ни слова.
Идея не самая свежая, картинка на скриншоте - красивая...
в остальном - "Не верю! (с) Станиславский
Репозиторий MorphBPE на GitHub пуст, единственный коммит — год назад, добавил
.gitignoreи заголовок в файлReadMe.mdчто не тянет даже на: "Официальный репозиторий с кодом. Пока минималистичный, но это reference implementation из статьи."
жаль, подача материала была многообещающей
Интереснее посмотреть на Qwen3, но сходу такое:
на llama-cpp-python 0.3.23 не "завелось". И кстати, Луиджи прямо пишет, что использует форк от JamePeng, который и сам прекрасно делает пребилды: https://github.com/JamePeng/llama-cpp-python/releases/
заказчики с разной степенью влияния;
Не ясно как удалось с помощью формата "магазина" решить эту проблему. У каждого заказчика свой лимит на долю капасити команды? Или кто первый "накидал фич в корзину" "того и тапки"?
Нет универсальных метрик OKR, которые позволили бы сравнивать фичи с точки зрения ценности для бизнеса?
Зачем? Если автоматическая проверка легко встраивается в пайплайн CI/CD и систему контроля версий?
А кто включил задачу на рефакторинг в бэклог и обозначил приоритет для команды разработки?
«Код понятен» и «знание кодовой базы» — это не одно и тоже. Ожидать, что разработчик будет «наизусть» знать кодовую базу среднего по размеру проекта как-то наивно даже.
Зачем, если с документацией к коду уже неплохо справляются автоинструменты?
Пока статья больше из серии «Делай хорошо и будет хорошо». Ни слова о прибыли для собственников, дедлайнах, межличностных отношениях в коллективе, «перетягивания одеяла».. Всё красиво — как по книжкам, а по факту — поверхностный взгляд на чудесную организацию в идеальных условиях
Много [лишних] букв. Но решение действительное любопытное. Благодарю за детальное описание и скрипт, надо попробовать в деле
Почему просто не взять готовые решения для бэктестов типа backtrader, Backtesting.py, не изобретать велосипед и не наступать на одни и те же грабли каждый раз (это про look-ahead bias). Тот же TA-lib для расчётов индикаторов? Зачем гнаться за скоростью, если HFT не является целью? Сомневаюсь, что на часовых свечах при ограниченном наборе инструментов подобные оптимизации имеют большое значение
Я даже пошёл было искать эту "шестеренку")
molyanov, если не секрет - как оплатили подписку?
Хорошая обзорная статья - всё сжато и по делу. Вот только без обработки исключений / ошибок, access / refresh токенов, ретрая, журналирования, расчета IO-метрик... до production ready всё равно ещё больше половины пути. Что удивительно - сценарий частый / проблема общая, каждый пишет свой велосипед, но так никто и не взялся за универсальный "комбайн"
Можно как-то остановить этот поток малоинформативных статей под эгидой АИС «Налог-3», единственной целью которых является раскрутка телеграм-канала автора?
https://habr.com/ru/articles/981988/
https://habr.com/ru/articles/982504/
https://habr.com/ru/articles/982686/
shtolman , в коммерции с договорённостями "на словах" тот же результат не заставит себя долго ждать. В целом юристы, аналитики, тестировщики, UX/UI дизайнеры - не зря свой хлеб едят, если демпенгуете на рынке и хотите закрыть все вопросы своими руками - трезво оценивайте все риски.
Если для заказчика проект непрофильный, то наивно ожидать там необходимых компетенций, дельных ТЗ, готовности брать на себя ответственность за решения по проекту. Редко когда отношение команды заказчика к исполнителю в проекте выходит за рамки: "хочешь заработать? сам и работай!" — никто не бросит свои текущие дела / задачи ради ваших сроков / доходов))
Никогда не встречал дотошных ТЗ у госов)) Повсеместно полно воды и копипаст из нормативки или других контрактов. Ткните пальцем на zakupki.gov если не сложно))
Как при чём? Сидит человек CVE list трекает, а за что в "зоопарке" в первую очередь хвататься - не знает. Или с другой стороны - платят деньги человеку, а хорошо ли / плохо ли он свою работу выполняет - непонятно...))
Тут к слову даже обосновать необходимость такого человека со сканером в руках сподручнее))) Но если денех на ИБ нет, то вопросов нет конечно))
Незаслуженно забыт Trivy
Как в итоге реализовали граф знаний (связи между статьями базы знаний)?
Годная статья, спасибо. Осталось отказаться от "велосипеда" и использовать готовые tenacity/stamina для retry,
asyncio.Task.cancelling()для Graceful shutdown))@thestratblog не совсем ясно — за чем OKR непосредственно командам? Обычно между командой и бизнесом есть владелец продукта и приоритезация задач, и конкретизация ожидаемых результатов для команды это его прямая обязанность, разве нет?