Очень интересная статья код к сожаленю не работает, не хватает настроек по ходу
Traceback (most recent call last): File "C:_work__llm\test.py", line 14, in model = PeftModel.from_pretrained( File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 332, in from_pretrained model.load_adapter(model_id, adapter_name, is_trainable=is_trainable, **kwargs) File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 662, in load_adapter dispatch_model( File "C:\bin\python\lib\site-packages\accelerate\big_modeling.py", line 368, in dispatch_model raise ValueError( ValueError: We need an offload_dir to dispatch this model according to this device_map, the following submodules need to be offloaded: base_model.model.model.layers.20, base_model.model.model.layers.21, base_model.model.model.layers.22, base_model.model.model.layers.23, base_model.model.model.layers.24, base_model.model.model.layers.25, base_model.model.model.layers.26, base_model.model.model.layers.27, base_model.model.model.layers.28, base_model.model.model.layers.29, base_model.model.model.layers.30, base_model.model.model.layers.31, base_model.model.model.norm, base_model.model.lm_head.
Ну я имею ввиду что бабла поток, но сама windows в этом потоке не asset а скорее все же liability. Не зря же SQL сервер на линукс портировали. Машина крутится и с этим нчиего не сделать, но выпендириваться с отдельной ОС становится все более и более обременительно.
Бизнес Микрософт давно уже не windows и не офис. Я так думаю если бы они могли windows как-то так хитро, безопасно для себя дропнуть, они бы это уже сделали бы. Оно им по бизнесу как я подозреваю денег то не сильно приносит.
Как чемодан без ручки - нести с каждым годом все неудобнее, а бросить нельзя.
Все так я об этом и пишу. Но увы сейчас в тех случаях которые я вижу как раз не "позволяет быстро выкатить стабильный релиз". Карго культ и все такое. Скорость упала, а стабильность не прибавилась
Я пожалуй не соглашусь - да количество всех сущностей IT мира неуклонно растет. Но и в 90-х из было дофига, просто тот кусочек который видели мы в РФ был действительно невелик. Просто не все до нас успело донестись.
В чем спасение, почему мы до сих пор не померли. Возьму привер с БД и дебианом. Сегодняшний генералист ответит - ну возьмите постгрес, он уже старый, надежнй, развивается, есть для всего и без багов. А те 30% возможного выигрыша, во первых если у вас фамилия не Маск и вы не запускаете корабль в космос (BTW панель управления в драконе на ноде!!!), то не факт что вы эти 30% заметите, а если заметите, то вот так митигируете. Да будет стоить на $10,000 больше на хотинге в год, но использование вот этой байды вам обойдется в $100,000+ на разработку. И не факт, что оно через 3 года не загнется.
Окно постоянно сдвигается, когда-то тот кто не умел паять IT-шником не считался. Сейчас можно не знать С++ и быть очень полезным специалистом широкого профиля.
Десть есть фундаментальные вещи, например что такое race condition и как правильно думать, чтобы его не было. Но таких вещей не так много и они как раз выучиваются за разумный срок это раз. Реально количество коитически важных штроким масссам для программирования вещей сокращается, это два.
Спасибо, это прям хорошее замечание, если с силами соберусь - в выходные добавлю к статье.
То о чем вы пишете это ортогональное изменение. Можно как вы описываете, можно еще десятком других способов.По опыту скажу, тот способ который у вас описан не самый эффективный в нем есть много подводных камней. Скажем SA у вас являет узким местом во всей этой системе. Но это не существенно.
Я пишу о том, что вне зависимости от того как вы эти тикеты туда сюда по доске двигаете и каких они у вас имеют типы, разбиение задач на тикеты должно быть определенного качества.
В строго иерархических системах, особенно в inhouse этот аспект не виден т.к. там часто роль равна фамилии и качество такое, какое оно есть.
Ну вот глядите - заполнили вы Эпик, Story расписали. Система у вас состоит из скажем 20 сервисов и еще скажем 5-и библиотечных репозиториев. И то что расписано в эпике отражается на скажем 4-х из них.
Если от эпика не сделать фазу планирования - что где и как менять то получается месиво даже при идеальных эпиках.
Все это дело сильно еще зависит от архитектуры и предметной области. Если у вас 3-х звенка и какое-то form/data driven приложение то истории определяют реализацию на 90%. А если платформа с дюжиной интеграций, на микросервисах, то там все намного интереснее
Ну обычно после прочтения пары учебников как раз то о чем вы пишете внедярется. Но вот дальше может начаться цирк с конями т.к. наличие эпиков и PO не гарантирует того что в эпиках не будет ереси. Собственно моя статья тоже не гарантирует, но я стрался дать какие-то более конкретные критерии.
Да тут беда в том что сейчас писательство статей вышло в довольно специфический жанр и то что я пишу в общем пользы мне почти не приносит. Так экономия времени, чтобы была возможность команде ссылку послать.
А то что пишется с профессиональными целями - пишется несколько иначе и про другое. Так то у меня тема вообще ни разу не хайповая.
Насчёт один PR для одного тикета. Часто разработчик делает много (реально много) PR-ов в Dev ветку по разным причинам:
Вот это для меня важный урок который я выучил лет 5 назад во время работы над большим репозиторием. Так как вы описываете можно работать только в очень сильно контролируемом окружении. Т.е. вы точно должны быть уверены, что PR пойдет в прод. А если нет? Будете откатывать частями?
Просто как пример - процедура ревью PR может быть такая
Я делаю фичу в ветке, тестирую, показываю команде
Апрув
Создаю PR строго на то что показывал
PR рассматривают, скажем дня 2. Оставляют комментарии, я что-то в PR фикшу
PR проходит серию сканов скажем сонаром
После всего этого делаем merge
.. далее идет несколько веселых шагов но я про них не буду
Частичный PR c "полработы" буедт послан нафиг на шаге 1.
Это несколько занудно но на большом объеме дает гранулярность и предсказуемость изменений.
UPD чистить надо, но я что-то забодался и понял что надо публиковать либо сейчас либо после отпуска который будет фиг знает когда, в ноябре наверное. Долго мариновать статью плохо. Давайте считать что кому надо через chat GPT прогонят. Я в общем все равно не для рейтинга пишу, а чтобы потом эти статьи коллегам как туториал давать. Такое прикладное писательство
Так это не работает. Надо на архитектуру смотреть, на то как команда работает. Какие внешние условия.
Я к тому, что реальный пример надо рассматривать вот прям с командой, диаграммой компонент и если речь идет о незнакомой системе, то прям с кодом.
Если ответ реально интересне, а не для докопаться, то могу дать совет - нарисуйте диаграмму компонентов, data flow и потом на ней стрелочками нарисуйте как пойдут изменнения и где изменения надо делать одним махом.
Поймите правильно - на прошлой неделе вот буквально разбирал похожее с одной из команд. При том что я знаком с системой и у меня под рукой был исходный код, в режиме звонка с показом экрана это заняло больше часа.
когда нужно ваш существующий API (это не обязательно именно API, это то, чем кто-то пользуется, например, формат файла) в результате разработки упростить, или сделать удобнее. И мы заранее не знаем, как именно
В таком случае надо сделать отдельную задачу на решить как упростить, закомитить драфт новой доки, посмотреть на это с коллегами и взять в следующий спринт. Там в статье про это немного есть.
С точки зрения управления зачем вам уменьшать число PR? Ради чего?
там прям ниже пример. Атомарность изменений это прям краеугольный камень в больших системах.
Ясно попробую питон снести и заново поставить. Спасибо
Очень интересная статья код к сожаленю не работает, не хватает настроек по ходу
Traceback (most recent call last):
File "C:_work__llm\test.py", line 14, in
model = PeftModel.from_pretrained(
File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 332, in from_pretrained
model.load_adapter(model_id, adapter_name, is_trainable=is_trainable, **kwargs)
File "C:\bin\python\lib\site-packages\peft\peft_model.py", line 662, in load_adapter
dispatch_model(
File "C:\bin\python\lib\site-packages\accelerate\big_modeling.py", line 368, in dispatch_model
raise ValueError(
ValueError: We need an
offload_dirto dispatch this model according to thisdevice_map, the following submodules need to be offloaded: base_model.model.model.layers.20, base_model.model.model.layers.21, base_model.model.model.layers.22, base_model.model.model.layers.23, base_model.model.model.layers.24, base_model.model.model.layers.25, base_model.model.model.layers.26, base_model.model.model.layers.27, base_model.model.model.layers.28, base_model.model.model.layers.29, base_model.model.model.layers.30, base_model.model.model.layers.31, base_model.model.model.norm, base_model.model.lm_head.Не понял, а где статья? Открыл, хотел почитать, а контента нет. Похоже текст не приложился. Поправьте пожалуйста
Ну я имею ввиду что бабла поток, но сама windows в этом потоке не asset а скорее все же liability. Не зря же SQL сервер на линукс портировали. Машина крутится и с этим нчиего не сделать, но выпендириваться с отдельной ОС становится все более и более обременительно.
Ну про "не приносит" я про то, что windows это часть в тех 24% которая постоянно падает.
Бизнес Микрософт давно уже не windows и не офис. Я так думаю если бы они могли windows как-то так хитро, безопасно для себя дропнуть, они бы это уже сделали бы. Оно им по бизнесу как я подозреваю денег то не сильно приносит.
Как чемодан без ручки - нести с каждым годом все неудобнее, а бросить нельзя.
Все так я об этом и пишу. Но увы сейчас в тех случаях которые я вижу как раз не "позволяет быстро выкатить стабильный релиз". Карго культ и все такое. Скорость упала, а стабильность не прибавилась
Интересно, а уже появились какие-то курсы для prompt инженеров?
Я пожалуй не соглашусь - да количество всех сущностей IT мира неуклонно растет. Но и в 90-х из было дофига, просто тот кусочек который видели мы в РФ был действительно невелик. Просто не все до нас успело донестись.
В чем спасение, почему мы до сих пор не померли. Возьму привер с БД и дебианом. Сегодняшний генералист ответит - ну возьмите постгрес, он уже старый, надежнй, развивается, есть для всего и без багов. А те 30% возможного выигрыша, во первых если у вас фамилия не Маск и вы не запускаете корабль в космос (BTW панель управления в драконе на ноде!!!), то не факт что вы эти 30% заметите, а если заметите, то вот так митигируете. Да будет стоить на $10,000 больше на хотинге в год, но использование вот этой байды вам обойдется в $100,000+ на разработку. И не факт, что оно через 3 года не загнется.
Окно постоянно сдвигается, когда-то тот кто не умел паять IT-шником не считался. Сейчас можно не знать С++ и быть очень полезным специалистом широкого профиля.
Десть есть фундаментальные вещи, например что такое race condition и как правильно думать, чтобы его не было. Но таких вещей не так много и они как раз выучиваются за разумный срок это раз. Реально количество коитически важных штроким масссам для программирования вещей сокращается, это два.
автор- фронтовик - сейчас звучит двусмысленно.
Но да фронтендеры не видят бОльшую часть мира. Go в анализе есть, хотя кто и что сейчас пишет на Go, а явы и C# нету
Спасибо, это прям хорошее замечание, если с силами соберусь - в выходные добавлю к статье.
То о чем вы пишете это ортогональное изменение. Можно как вы описываете, можно еще десятком других способов.По опыту скажу, тот способ который у вас описан не самый эффективный в нем есть много подводных камней. Скажем SA у вас являет узким местом во всей этой системе. Но это не существенно.
Я пишу о том, что вне зависимости от того как вы эти тикеты туда сюда по доске двигаете и каких они у вас имеют типы, разбиение задач на тикеты должно быть определенного качества.
В строго иерархических системах, особенно в inhouse этот аспект не виден т.к. там часто роль равна фамилии и качество такое, какое оно есть.
Ну вот глядите - заполнили вы Эпик, Story расписали. Система у вас состоит из скажем 20 сервисов и еще скажем 5-и библиотечных репозиториев. И то что расписано в эпике отражается на скажем 4-х из них.
Если от эпика не сделать фазу планирования - что где и как менять то получается месиво даже при идеальных эпиках.
Все это дело сильно еще зависит от архитектуры и предметной области. Если у вас 3-х звенка и какое-то form/data driven приложение то истории определяют реализацию на 90%. А если платформа с дюжиной интеграций, на микросервисах, то там все намного интереснее
Ну обычно после прочтения пары учебников как раз то о чем вы пишете внедярется. Но вот дальше может начаться цирк с конями т.к. наличие эпиков и PO не гарантирует того что в эпиках не будет ереси. Собственно моя статья тоже не гарантирует, но я стрался дать какие-то более конкретные критерии.
:-) как раз это и имеется ввиду. Изменения не паста которая давится из тюбика, а гранула одна за другой.
Да тут беда в том что сейчас писательство статей вышло в довольно специфический жанр и то что я пишу в общем пользы мне почти не приносит. Так экономия времени, чтобы была возможность команде ссылку послать.
А то что пишется с профессиональными целями - пишется несколько иначе и про другое. Так то у меня тема вообще ни разу не хайповая.
Статья немного про другое. Все о чем вы говорите можно делать сильно по разному и не во всех проектах есть РП и РО (не знаю, даже, что это значит).
Вот это для меня важный урок который я выучил лет 5 назад во время работы над большим репозиторием. Так как вы описываете можно работать только в очень сильно контролируемом окружении. Т.е. вы точно должны быть уверены, что PR пойдет в прод. А если нет? Будете откатывать частями?
Просто как пример - процедура ревью PR может быть такая
Я делаю фичу в ветке, тестирую, показываю команде
Апрув
Создаю PR строго на то что показывал
PR рассматривают, скажем дня 2. Оставляют комментарии, я что-то в PR фикшу
PR проходит серию сканов скажем сонаром
После всего этого делаем merge
.. далее идет несколько веселых шагов но я про них не буду
Частичный PR c "полработы" буедт послан нафиг на шаге 1.
Это несколько занудно но на большом объеме дает гранулярность и предсказуемость изменений.
UPD чистить надо, но я что-то забодался и понял что надо публиковать либо сейчас либо после отпуска который будет фиг знает когда, в ноябре наверное. Долго мариновать статью плохо. Давайте считать что кому надо через chat GPT прогонят. Я в общем все равно не для рейтинга пишу, а чтобы потом эти статьи коллегам как туториал давать. Такое прикладное писательство
Так это не работает. Надо на архитектуру смотреть, на то как команда работает. Какие внешние условия.
Я к тому, что реальный пример надо рассматривать вот прям с командой, диаграммой компонент и если речь идет о незнакомой системе, то прям с кодом.
Если ответ реально интересне, а не для докопаться, то могу дать совет - нарисуйте диаграмму компонентов, data flow и потом на ней стрелочками нарисуйте как пойдут изменнения и где изменения надо делать одним махом.
Поймите правильно - на прошлой неделе вот буквально разбирал похожее с одной из команд. При том что я знаком с системой и у меня под рукой был исходный код, в режиме звонка с показом экрана это заняло больше часа.
В таком случае надо сделать отдельную задачу на решить как упростить, закомитить драфт новой доки, посмотреть на это с коллегами и взять в следующий спринт. Там в статье про это немного есть.
там прям ниже пример. Атомарность изменений это прям краеугольный камень в больших системах.
Спасибо, как-то я на этот вопрос под таким углом не смотрел.