Последние пару недель гоняю прикладные кодинговые задачи на ней из-под Roo Code (оркестратор, кодер, архитектор) с квантом ud_q4_k_xl, никаких зацикливаний не возникало. А у 3.5 при тех же квантах и параметрах запуска производительность ниже и контекст даёт меньше.
Чаще всего наоборот сталкиваюсь с тем, что приходится искать способ запуска приложений, которые мне нужно как-то отлаживать, в английской локали. Потому что русскоязычная часть интернета практически по всем ЯП/фреймворкам/библиотекам/инструментам настолько маленькая, что вероятность найти ответ на свою проблему, сформулированную на русском языке, стремится к нулю. Особенно с учётом все возрастающей скорости генерации новых инструментов. Просто скопипастить ошибку из лога на английском и в крайнем случае перевести в браузере через ПКМ намного проще. А лучше все же подтянуть язык для чтения технических текстов, это не так сложно. Ведь опять же, вся документация на английском. У Майков автоперевод в доках есть, иной раз такие перлы выдаёт, что и понять невозможно, о чем тут речь.
... и если гугл не скажет в один прекрасный момент, что вы - человек второго сорта, у вас осталось 2 дня, чтобы скопировать ваши коды, а потом мы их удалим. Лучше все же иметь как минимум два устройства со вторым фактором.
После того, как мой коллега принёс из офиса Сбера (!) распечатку какой-то фигни на чужом расчёте по ипотеке, я перестал удивляться вообще. Правда, было лет 10 назвд. А с учётом того, сколько различных договоров с шарашкиными конторами приходится подписывать, сохранить свои ПДН в ограниченном доступе все сложнее и сложнее. Проще паспорт раз в 3 года менять.
Вместо того, чтобы подобрать дешёвую (возможно, облачную) систему организации процесса или хотя бы готовый BPM (ведь любой знает, что у заявки есть статусы и согласования?), техлид решил изобрести велосипед и пройтись по всем граблям, по которым эти системы уже прошли, и добавить своих в виде тележки. Очень дальновидно. Ну а собственно AI-картинки в тексте с этой самой статусной схемой отлично показывают, почему все посыпалось сразу же: рандомный набор с рандомными переходами и дублями.
В конце должен быть иной вывод: не надо пытаться заткнуть дырку в процессе тряпкой AI-кода, стоит задуматься о выстраивании процесса.
Было бы странно, если бы люди, продающие ИИ-продукты, говорили: "Ну используем в работе для базовых нужд, а потом дописываем руками". Ожидание магии само собой не появится и подписка сама себя не купит.
У flowgraph же как раз супер прямой синтаксис: узел, срелка, текст, узел. Уж точно проще, чем плясать с фиктивными узлами, как это сейчас делается в PlantUML, когда несколько вложенных условий ведут в одинаковое состояние.
В последнее время mermaid сильно потянулся по функционалу. Для себя всегда использовал его, Gitlab на работе умеет сам рендерить в Web интерфейсе, удобно. Но отсутствие стандартного плагина для Confluence постоянно вызывало необходимость все перерисовать на PlantUML.
Excel, Google Sheets, Python, Яндекс Диск, Telegram (для которого надо ещё где-то самого бота захостить) - это же сущий ад в сопровождении и ИБ. Задачу трансформации можно решать средствами Power Query не выходя за пределы Excel, раз уж нет BI, и передача данных из контура также не потребуется. Но грустно, что в крупном маркетплейсе нет возможности выделить себе в BI песочницу и джоинить там что хочешь, либо настроить перманентную интеграцию с источником, чтобы не городить такие неконтролируемые потоки данных.
Следующим этапом на пути снижения порога входа должно стать добавление Управляющего Связками владус и опций к нему: владус начать , владус добавить математика, владус список. Тут тоже можно без парсера обойтись, достаточно разбивателянапростыечасти токенизации и сопоставлятеля меппинга.
Этот финт работает либо с зелёными не разбирающимся в ТК новичками (а заодно и тема с переработками заходит отлично), либо в шарашкиных конторах, которые эксплуатируют людей и построены чисто на понятиях и ничем не подкрепленной вере на слово. Последние, как по мне, надо вообще обходить на версту, чтобы вымирали как класс. Пришедшая пару раз трудовая инспекция быстро обеспечит болезнь не "попозже", а сейчас.
Сам работал и в консалтингах, и в производстве. Везде все было по договору, ЗП два раза в указанные числа месяца, отпуск 28 дней с принудительным оформлением 14-дневной части, если не завел, больничный как больничный (его вообще ФСС/ПФ оплачивает), работа в выходные по двойной или с отгулом (по предварительной человеческой просьбе с последующим приказом). А ещё нормальный ДМС, и где-то даже корп связь и доплата больничного до 100% на некоторый срок. Так что вы пересмотрите приоритеты, поинтересуйтесь компаниями 700+ человек хотя бы, не все не-госкомпании помоечны.
Через rebase можно перенести коммиты на произвольный другой коммит, очень удобный "мультитул", в работе пользуюсь часто:
реанимируем старую фичу, переносим точку ветвления на более свежий коммит, чтобы не откладывать конфликты
подчищаем историю перед пушем, собираем мелкие правки к основному коммиту (можно сколько угодно править частями и коммитить с указанием --fixup commit_sha, а потом разобраться спокойно в интерактивном/autosquash ребейзе)
"вырезать" часть ветки и перекинуть в другую (кривая история/точка ветвления/набился какой-то мусор/etc), разделить/слить коммиты
В статье указано не совсем корректно: старые коммиты не удаляются на самом деле, а лежат сами по себе, на них можно переключиться по sha и сделать веточку. В связке с reflog можно потом откатить неудачные эксперименты.
А вот историю на самом деле удобнее смотреть в IDE. В VS Code отличный плагин с графом, также отдельно показывается таймлайн по открытому файлу с указанием и git, и истории просто сохранений без коммитов. Упражнения с консолью нужны только для каких-то автоматизаций типа собрать задачи в MR/PR.
Как интересно, тоже моделировал восприятие этого как интервалов времени относительно какой-то точки в ортогональном измерении: past/present/future - обычное (как и в русском языке) время наблюдателя, simple/continuous/perfect/perfect continuous - характеристика процесса для наблюдателя. Только с интервалами у меня получилось чуть иначе:
simple - (-∞, +∞) - рутина, которая условно бесконечна (не учитываем, что все когда-то исчезнет)
continuous - (-x1, +x2) - некоторая окрестность точки (т.е. что-то началось до наблюдения и завершится когда-то в будущем от наблюдения, но границу не знаем/не интересует), процесс идёт сейчас
perfect - (-x1, -x2] - что-то началось до наблюдения (не важно, когда именно) и завершено к моменту наблюдения
perfect continuous - [-x1, +x2) - что-то началось до наблюдения понятно когда (= имеет явную длительность к моменту наблюдения) и продолжается сейчас
А статья, вообще говоря, разбирает не проблему выяснения предпосылок для образования формы (в которой и заключается 90% сложности), а механику образования формы, которая достаточно проста.
Что за велосипед из YAML и CSV? Если хоть один объект в массиве содержит не скалярный атрибут, то это превращается в обычный YAML с явным указанием числа элементов массива. Зачем? В случае массива "плоских" объектов будет CSV опять же с указанием числа элементов. Снова: зачем?
В 101 раз повторено одно и то же с упрощёнными примерами, а таким важным вещам, как типизация, уделена одна строчка между делом. data.get("username") почему-то не попадает под критикуемую далее категорию магических констант. Хотя не раз в одном продукте видел user_name в одном месте и username в другом. И где тот интересный баланс между YAGNI и обкладыванием dataclass'ами всего подряд? Или выбор между NamedTuple и dataclass? Или вообще протоколом?
Из интересного увидел только использование ветки else в try: впервые встречаю среди прочитанного кода, и очень интересная рекомендация по использованию: вынести в try только потенциально опасный кусок. А как же читаемость? Код друг за другом - все понятно, ожидаемые исключения в конце ветками - тоже понятно. А эта конструкция смотрится странно, даже интересно, что вдохновило дизайнеров языка на такое. Какая реальная польза от else вместо описания happy-path и обработки разных исключений разом без детализации, кто же там споткнулся?
Скорее всего потому, что это курсовая/дипломная работа, судя по структуре и nir_7_semestr. Часто наблюдаемое явление: из питона по простому импорту CSV пушки по воробьям. В целом, если бы модели были объявлены через классы orm и менялся только энджин в алхимии, прилагался код-запускатор запросов и измеритель времени выполнения, сбрасыватель кешей/буферов и т.п (короче говоря, готовая настройка тестов), можно было бы сказать, что для простоты автоматизации и измерений. Но тут он просто потому что. Учитывая ещё то, что файлы локальные, и все названные СУБД умеют импортировать CSV нативной, без внешнего pandas.
При найме будем платить, чтобы потом этого сотрудника на наш родненький ии заменять, с березками и кокошником
Последние пару недель гоняю прикладные кодинговые задачи на ней из-под Roo Code (оркестратор, кодер, архитектор) с квантом ud_q4_k_xl, никаких зацикливаний не возникало. А у 3.5 при тех же квантах и параметрах запуска производительность ниже и контекст даёт меньше.
Чаще всего наоборот сталкиваюсь с тем, что приходится искать способ запуска приложений, которые мне нужно как-то отлаживать, в английской локали. Потому что русскоязычная часть интернета практически по всем ЯП/фреймворкам/библиотекам/инструментам настолько маленькая, что вероятность найти ответ на свою проблему, сформулированную на русском языке, стремится к нулю. Особенно с учётом все возрастающей скорости генерации новых инструментов. Просто скопипастить ошибку из лога на английском и в крайнем случае перевести в браузере через ПКМ намного проще. А лучше все же подтянуть язык для чтения технических текстов, это не так сложно. Ведь опять же, вся документация на английском. У Майков автоперевод в доках есть, иной раз такие перлы выдаёт, что и понять невозможно, о чем тут речь.
... и если гугл не скажет в один прекрасный момент, что вы - человек второго сорта, у вас осталось 2 дня, чтобы скопировать ваши коды, а потом мы их удалим. Лучше все же иметь как минимум два устройства со вторым фактором.
После того, как мой коллега принёс из офиса Сбера (!) распечатку какой-то фигни на чужом расчёте по ипотеке, я перестал удивляться вообще. Правда, было лет 10 назвд. А с учётом того, сколько различных договоров с шарашкиными конторами приходится подписывать, сохранить свои ПДН в ограниченном доступе все сложнее и сложнее. Проще паспорт раз в 3 года менять.
Вместо того, чтобы подобрать дешёвую (возможно, облачную) систему организации процесса или хотя бы готовый BPM (ведь любой знает, что у заявки есть статусы и согласования?), техлид решил изобрести велосипед и пройтись по всем граблям, по которым эти системы уже прошли, и добавить своих в виде тележки. Очень дальновидно. Ну а собственно AI-картинки в тексте с этой самой статусной схемой отлично показывают, почему все посыпалось сразу же: рандомный набор с рандомными переходами и дублями.
В конце должен быть иной вывод: не надо пытаться заткнуть дырку в процессе тряпкой AI-кода, стоит задуматься о выстраивании процесса.
Наглядно показал, что будет, если сильно расширять канал, и уточнил, кому нужно объяснить подробнее
Было бы странно, если бы люди, продающие ИИ-продукты, говорили: "Ну используем в работе для базовых нужд, а потом дописываем руками". Ожидание магии само собой не появится и подписка сама себя не купит.
У flowgraph же как раз супер прямой синтаксис: узел, срелка, текст, узел. Уж точно проще, чем плясать с фиктивными узлами, как это сейчас делается в PlantUML, когда несколько вложенных условий ведут в одинаковое состояние.
В последнее время mermaid сильно потянулся по функционалу. Для себя всегда использовал его, Gitlab на работе умеет сам рендерить в Web интерфейсе, удобно. Но отсутствие стандартного плагина для Confluence постоянно вызывало необходимость все перерисовать на PlantUML.
Тоже все ждал, что будет про components. Куда более явно декларированная параметризация, и шарится сразу на весь инстанс, а не группу проектов.
Excel, Google Sheets, Python, Яндекс Диск, Telegram (для которого надо ещё где-то самого бота захостить) - это же сущий ад в сопровождении и ИБ. Задачу трансформации можно решать средствами Power Query не выходя за пределы Excel, раз уж нет BI, и передача данных из контура также не потребуется. Но грустно, что в крупном маркетплейсе нет возможности выделить себе в BI песочницу и джоинить там что хочешь, либо настроить перманентную интеграцию с источником, чтобы не городить такие неконтролируемые потоки данных.
Следующим этапом на пути снижения порога входа должно стать добавление Управляющего Связками
владуси опций к нему:владус начать,владус добавить математика,владус список. Тут тоже можно без парсера обойтись, достаточноразбивателянапростыечаститокенизации исопоставлятелямеппинга.В общем, обои пока скучные.
Этот финт работает либо с зелёными не разбирающимся в ТК новичками (а заодно и тема с переработками заходит отлично), либо в шарашкиных конторах, которые эксплуатируют людей и построены чисто на понятиях и ничем не подкрепленной вере на слово. Последние, как по мне, надо вообще обходить на версту, чтобы вымирали как класс. Пришедшая пару раз трудовая инспекция быстро обеспечит болезнь не "попозже", а сейчас.
Сам работал и в консалтингах, и в производстве. Везде все было по договору, ЗП два раза в указанные числа месяца, отпуск 28 дней с принудительным оформлением 14-дневной части, если не завел, больничный как больничный (его вообще ФСС/ПФ оплачивает), работа в выходные по двойной или с отгулом (по предварительной человеческой просьбе с последующим приказом). А ещё нормальный ДМС, и где-то даже корп связь и доплата больничного до 100% на некоторый срок. Так что вы пересмотрите приоритеты, поинтересуйтесь компаниями 700+ человек хотя бы, не все не-госкомпании помоечны.
Через rebase можно перенести коммиты на произвольный другой коммит, очень удобный "мультитул", в работе пользуюсь часто:
реанимируем старую фичу, переносим точку ветвления на более свежий коммит, чтобы не откладывать конфликты
подчищаем историю перед пушем, собираем мелкие правки к основному коммиту (можно сколько угодно править частями и коммитить с указанием
--fixup commit_sha, а потом разобраться спокойно в интерактивном/autosquash ребейзе)"вырезать" часть ветки и перекинуть в другую (кривая история/точка ветвления/набился какой-то мусор/etc), разделить/слить коммиты
В статье указано не совсем корректно: старые коммиты не удаляются на самом деле, а лежат сами по себе, на них можно переключиться по sha и сделать веточку. В связке с reflog можно потом откатить неудачные эксперименты.
А вот историю на самом деле удобнее смотреть в IDE. В VS Code отличный плагин с графом, также отдельно показывается таймлайн по открытому файлу с указанием и git, и истории просто сохранений без коммитов. Упражнения с консолью нужны только для каких-то автоматизаций типа собрать задачи в MR/PR.
Как интересно, тоже моделировал восприятие этого как интервалов времени относительно какой-то точки в ортогональном измерении: past/present/future - обычное (как и в русском языке) время наблюдателя, simple/continuous/perfect/perfect continuous - характеристика процесса для наблюдателя. Только с интервалами у меня получилось чуть иначе:
simple - (-∞, +∞) - рутина, которая условно бесконечна (не учитываем, что все когда-то исчезнет)
continuous - (-x1, +x2) - некоторая окрестность точки (т.е. что-то началось до наблюдения и завершится когда-то в будущем от наблюдения, но границу не знаем/не интересует), процесс идёт сейчас
perfect - (-x1, -x2] - что-то началось до наблюдения (не важно, когда именно) и завершено к моменту наблюдения
perfect continuous - [-x1, +x2) - что-то началось до наблюдения понятно когда (= имеет явную длительность к моменту наблюдения) и продолжается сейчас
А статья, вообще говоря, разбирает не проблему выяснения предпосылок для образования формы (в которой и заключается 90% сложности), а механику образования формы, которая достаточно проста.
Это же шутка, да?)
https://about.readthedocs.com/
https://pypi.org/
https://www.python.org/
https://kubernetes.io/docs/home/
При этом: https://peps.python.org/pep-0000/
Что за велосипед из YAML и CSV? Если хоть один объект в массиве содержит не скалярный атрибут, то это превращается в обычный YAML с явным указанием числа элементов массива. Зачем? В случае массива "плоских" объектов будет CSV опять же с указанием числа элементов. Снова: зачем?
В 101 раз повторено одно и то же с упрощёнными примерами, а таким важным вещам, как типизация, уделена одна строчка между делом.
data.get("username")почему-то не попадает под критикуемую далее категорию магических констант. Хотя не раз в одном продукте виделuser_nameв одном месте иusernameв другом. И где тот интересный баланс между YAGNI и обкладыванием dataclass'ами всего подряд? Или выбор между NamedTuple и dataclass? Или вообще протоколом?Из интересного увидел только использование ветки
elseвtry: впервые встречаю среди прочитанного кода, и очень интересная рекомендация по использованию: вынести вtryтолько потенциально опасный кусок. А как же читаемость? Код друг за другом - все понятно, ожидаемые исключения в конце ветками - тоже понятно. А эта конструкция смотрится странно, даже интересно, что вдохновило дизайнеров языка на такое. Какая реальная польза отelseвместо описания happy-path и обработки разных исключений разом без детализации, кто же там споткнулся?Скорее всего потому, что это курсовая/дипломная работа, судя по структуре и
nir_7_semestr. Часто наблюдаемое явление: изпитона по простому импорту CSVпушки по воробьям. В целом, если бы модели были объявлены через классы orm и менялся только энджин в алхимии, прилагался код-запускатор запросов и измеритель времени выполнения, сбрасыватель кешей/буферов и т.п (короче говоря, готовая настройка тестов), можно было бы сказать, что для простоты автоматизации и измерений. Но тут он просто потому что. Учитывая ещё то, что файлы локальные, и все названные СУБД умеют импортировать CSV нативной, без внешнего pandas.