С самим посылом не спорю, но в деталях у вас набор неактуальных штампов:
какие-то допуски
Не обязательно, секретность не прям чтобы на каждом предприятии будет, тем более для разраба\сисадмина.
оффлайн офис
Не обязательно, в ковидные времена даже конструкторов спокойно на удаленку отпускали.
отсутствие интернета
Да есть интернет на производстве, он для работы нужен, откуда вы это взяли.
старье (как люди, так и технологии)
Не встречал никаких орд замшелых дедов на предприятиях. Что инженеры, что заводоуправление -- это контингент до 50 лет. Вот про технологии соглашусь, легаси -- это бич любого крупного предприятия. Но и здесь сильно зависит от того куда попадешь.
зп на уровне дефолт инженера
Нуу, скорее нет, сотрудник ДИТ на заводе в среднем получает больше конструктора\технолога. Но не сильно, скорее всего х1.5.
Наркошопы очень даже активно рекламируются. И IRL, и на специализированных ресурсах и у блогеров рекламу закупают. Видимо, вы далеки от целевой аудитории, поэтому не в курсе.
MoE модели реально столько выдают на старте, но как только в контекст набивается несколько тысяч токенов, то скорость падает до 9-10 t\s (что все еще очень неплохо)
!20к на севере? Ну, разве что если разнорабочим едешь без квалификации, гайки крутить. Для инженера ЗП может плавать от 300к до 800к за смену.
И как там 85к потратить за месяц? Вахта, конечно, разная бывает, но на северах нефтянники обычно живут в рабочем городке посреди ничего. Да, там будет магазин , где можно купить шоколадку и сигареты с наценкой, но потратить в этом магазине 85к -- это надо постараться. А питание -- в столовой за счет работодателя.
Мне не нравится, что новые возможности вводят не разработчики - пользователи продукта, а его производители, тем самым - навязывая эти возможности всем - и желающим их, и не желающим.
Эм, но это совсем нет так -- есть фича реквесты от коммьюнити, их создают как индивидуальные разработчики, так и компании. У вторых, конечно, есть отдельные каналы и больший приоритет (потому что они платят за это деньги), но сути дела это не меняет.
Вы почему-то не видете другую сторону этого процесса - трудозатраты на освоение новых возможностей.
Ну а вы игнорируете факт того что новая функциональность появляется не просто так, для того что бы закрыть какие-то вполне конкретные проблемы разработчиков. И что профит от внедрения фичи многократно превышает время на её освоение. Если у вас этих проблем нет, то значит вам фича вам не нужна и вы можете просто ей не пользоваться.
Ну и в конце концов, если подумать, какие такие фичи появились в C# (за последние 15 лет, например), чтобы их освоение занимало какое-то существенно время? Я могу только появление async\await вспомнить как пример такой сложной фичи. Но я не думаю, что кому-то в голову придет выкинуть её из языка.
И вы же предлагаете лишить других разработчиков потенциально полезных для них возможностей, прикрываясь каким-то абстрактным "ну нужно чтоб баланс был". Так а может текущий темп развития и соответствует этому самому балансу? Так что это вообще не аргумент. Приведите тогда хотя бы пример фич, которые реально портят вам жизнь, чтобы был хоть какой-то предмет для обсуждения.
Эм, единый интерфейс, как ни странно, определяют при помощи... интерфейсов. А виртуальные методы -- это же просто встроенная возможность языка переопределять методы наследуемого класса, при чем тут они?
Например, у нас в коде определены несколько сущностей с похожим функционалом -- Cat, Dog, Human, реализующие метод Run(). Если мы хотим в коде смоделировать стадион, по которому будут бегать экземпляры наших людей, кошек и собак (т.е. нам не важно как именно бегает конкретный инстанс объекта, на четырех ногах или на двух, нам важно только знать, что этот объект умеет бегать), то что мы будем использовать? Виртуальные методы (честное слово, не представляю как) или все-таки для этого используются интерфейсы?
При чем тут Virtual Function, что из того что я описал хоть как-то может относиться к виртуальным функциям?
И я описал для чего этот паттерн обычно используется, а вы зачем-то в качестве контраргумента привели одно из определений паттерна, это вообще перпендикулярные вещи.
Вы не согласны именно с моим утверждением про то что это паттерн "для объединения множества операций под единым интерфейсом" или с тем что у реализации этого паттерна не обязательно должны быть внешние зависимости?
command, этот антипаттерн, потому что скрывает за командами реальные классы и модули
Ну тогда по вашим словам принципиально любое инкапсулирование логики в классах будет усложнять читаемость. И тогда 90% паттернов -- это антипаттерны, потому что в них предполагается передача зависимостей через конструктор.
это усложняет поиск класса которы привязан к команде
Каким образом? Все зависимости читаются в конструкторе класса (команды в нашем случае). Либо прямо по месту использования можно по одному клику провалиться в реализацию интересующего нас метода.
Ну и паттерн "Команда" не про это вообще -- у команды может и не быть внешних зависимостей, никто не запрещает логику прямо в классе команды реализовать. Он (этот паттерн) нужен исключительно как подход для объединения множества операций под единым интерфейсом.
Например, классический пример -- это реализация undo\redo функционала в приложении. Приложение фиксирует последовательность команд, запущенных пользователем и если все команды закрыты одним интерфейсом
то, при необходимости откатить изменения, мы можем просто вытягивать элементы стэка _commandsHistory и вызывать ICommand.Undo(), абстрагировавшись от реализации этих самых команд.
Если модель чего-то не знает, то ей нужно просто эти данные явно предоставить. Если говорим о какой-то редкой\новой библиотеке, то можно добавить в промпт документацию и\или примеры использования.
Скорее всего, результат с первой попытки будет не очень, но можно в несколько этапов дать нужные инструкции. Ну и никто не запрещает допилить руками итоговый результат.
Но если нормальной документации нет или ее слишком много, чтобы влезть в контекстное окно, то тут уже будут проблемы, да.
В штатной поставке очень большая библиотека: от хелперов для даты и времени, строк, чисел и т.д. до методов шифрования, хеширования, кодировки и т.п. В штатной поставке есть даже библиотека для работы с любыми S3-compatibility хранилищами и библиотека для клиент-серверной трансляции.
Так и в любом зрелом языке все это есть, в чем преимущество-то?
Всё это есть из коробки и не нужно бороться с зоопарком библиотек и их версий.
Да нет никакой борьбы в том чтобы нужные библиотеки подтянуть пакетным менеджером. Ну и в .NET и Java, например, большая часть тоже из коробки есть и не надо даже в пакетный менеджер лазить.
VS живее всех живых, никакого курса на замену его на VSC нет (и не было). Вся энтерпрайзная разработка под .NET вообще живет либо на VS, либо на Rider от JetBrains. VS Code это замечательный универсальный редактор кода, но все равно не полноценная IDE.
Не, я помню конечно тот период времени на взлете VSC когда про него везде писали что это бесплатная кросcплатформенная альтернатива VS, но сами майки никогда так его не позиционировали и время показало что это два разных продукта, для разных задач, хоть и с пересекающимся функционалом.
Получение саммари к Whisper никакого отношения не имеет, это модель для перевода аудио в текст.
Если хотите чтоб саммари локально генерировался, то придется рядом с whisper разворачивать LLM (делается просто через UI, при помощи LM Studio, например) и руками уже в чат закидывать файл стенограммы с нужной инструкцией.
Ссылка не открывается -- 404. Может репозиторий приватный?
С самим посылом не спорю, но в деталях у вас набор неактуальных штампов:
Не обязательно, секретность не прям чтобы на каждом предприятии будет, тем более для разраба\сисадмина.
Не обязательно, в ковидные времена даже конструкторов спокойно на удаленку отпускали.
Да есть интернет на производстве, он для работы нужен, откуда вы это взяли.
Не встречал никаких орд замшелых дедов на предприятиях. Что инженеры, что заводоуправление -- это контингент до 50 лет. Вот про технологии соглашусь, легаси -- это бич любого крупного предприятия. Но и здесь сильно зависит от того куда попадешь.
Нуу, скорее нет, сотрудник ДИТ на заводе в среднем получает больше конструктора\технолога. Но не сильно, скорее всего х1.5.
Наркошопы очень даже активно рекламируются. И IRL, и на специализированных ресурсах и у блогеров рекламу закупают. Видимо, вы далеки от целевой аудитории, поэтому не в курсе.
MoE модели реально столько выдают на старте, но как только в контекст набивается несколько тысяч токенов, то скорость падает до 9-10 t\s (что все еще очень неплохо)
Зачем это делать, если можно на винформах по-быстрому набросать UI, который делает ровно то же самое?
Зачем пихать в докер приложение, которое работает с файловой системой?
Спасибо за статью и проект, выглядит интересно. Проект, связанный с AI, на dotnet нечасто увидишь.
Планируете развивать приложение или просто делали ради эксперимента?
!20к на севере? Ну, разве что если разнорабочим едешь без квалификации, гайки крутить. Для инженера ЗП может плавать от 300к до 800к за смену.
И как там 85к потратить за месяц? Вахта, конечно, разная бывает, но на северах нефтянники обычно живут в рабочем городке посреди ничего. Да, там будет магазин , где можно купить шоколадку и сигареты с наценкой, но потратить в этом магазине 85к -- это надо постараться. А питание -- в столовой за счет работодателя.
ЛЛМ детектаble
Эм, но это совсем нет так -- есть фича реквесты от коммьюнити, их создают как индивидуальные разработчики, так и компании. У вторых, конечно, есть отдельные каналы и больший приоритет (потому что они платят за это деньги), но сути дела это не меняет.
Ну а вы игнорируете факт того что новая функциональность появляется не просто так, для того что бы закрыть какие-то вполне конкретные проблемы разработчиков. И что профит от внедрения фичи многократно превышает время на её освоение. Если у вас этих проблем нет, то значит вам фича вам не нужна и вы можете просто ей не пользоваться.
Ну и в конце концов, если подумать, какие такие фичи появились в C# (за последние 15 лет, например), чтобы их освоение занимало какое-то существенно время? Я могу только появление async\await вспомнить как пример такой сложной фичи. Но я не думаю, что кому-то в голову придет выкинуть её из языка.
И вы же предлагаете лишить других разработчиков потенциально полезных для них возможностей, прикрываясь каким-то абстрактным "ну нужно чтоб баланс был". Так а может текущий темп развития и соответствует этому самому балансу? Так что это вообще не аргумент. Приведите тогда хотя бы пример фич, которые реально портят вам жизнь, чтобы был хоть какой-то предмет для обсуждения.
И какие проблемы это создает?
Если очень нужно отвязаться от реализации, то никто не мешает вызов статических методов вынести в отдельный класс и закрыть его интерфейсом.
А какое отношение эти две фичи имеют к функциональности языка?
Первое -- это про EF, а не про сам язык, второе -- вообще просто добавление экстеншен-метода в библиотеке System.Net.Http.Json.
Эм, единый интерфейс, как ни странно, определяют при помощи... интерфейсов. А виртуальные методы -- это же просто встроенная возможность языка переопределять методы наследуемого класса, при чем тут они?
Например, у нас в коде определены несколько сущностей с похожим функционалом -- Cat, Dog, Human, реализующие метод Run(). Если мы хотим в коде смоделировать стадион, по которому будут бегать экземпляры наших людей, кошек и собак (т.е. нам не важно как именно бегает конкретный инстанс объекта, на четырех ногах или на двух, нам важно только знать, что этот объект умеет бегать), то что мы будем использовать? Виртуальные методы (честное слово, не представляю как) или все-таки для этого используются интерфейсы?
При чем тут Virtual Function, что из того что я описал хоть как-то может относиться к виртуальным функциям?
И я описал для чего этот паттерн обычно используется, а вы зачем-то в качестве контраргумента привели одно из определений паттерна, это вообще перпендикулярные вещи.
Вы не согласны именно с моим утверждением про то что это паттерн "для объединения множества операций под единым интерфейсом" или с тем что у реализации этого паттерна не обязательно должны быть внешние зависимости?
Ну тогда по вашим словам принципиально любое инкапсулирование логики в классах будет усложнять читаемость. И тогда 90% паттернов -- это антипаттерны, потому что в них предполагается передача зависимостей через конструктор.
Каким образом? Все зависимости читаются в конструкторе класса (команды в нашем случае). Либо прямо по месту использования можно по одному клику провалиться в реализацию интересующего нас метода.
Ну и паттерн "Команда" не про это вообще -- у команды может и не быть внешних зависимостей, никто не запрещает логику прямо в классе команды реализовать. Он (этот паттерн) нужен исключительно как подход для объединения множества операций под единым интерфейсом.
Например, классический пример -- это реализация undo\redo функционала в приложении. Приложение фиксирует последовательность команд, запущенных пользователем и если все команды закрыты одним интерфейсом
то, при необходимости откатить изменения, мы можем просто вытягивать элементы стэка _commandsHistory и вызывать ICommand.Undo(), абстрагировавшись от реализации этих самых команд.
Если модель чего-то не знает, то ей нужно просто эти данные явно предоставить. Если говорим о какой-то редкой\новой библиотеке, то можно добавить в промпт документацию и\или примеры использования.
Скорее всего, результат с первой попытки будет не очень, но можно в несколько этапов дать нужные инструкции. Ну и никто не запрещает допилить руками итоговый результат.
Но если нормальной документации нет или ее слишком много, чтобы влезть в контекстное окно, то тут уже будут проблемы, да.
Так и в любом зрелом языке все это есть, в чем преимущество-то?
Да нет никакой борьбы в том чтобы нужные библиотеки подтянуть пакетным менеджером. Ну и в .NET и Java, например, большая часть тоже из коробки есть и не надо даже в пакетный менеджер лазить.
VS живее всех живых, никакого курса на замену его на VSC нет (и не было). Вся энтерпрайзная разработка под .NET вообще живет либо на VS, либо на Rider от JetBrains. VS Code это замечательный универсальный редактор кода, но все равно не полноценная IDE.
Не, я помню конечно тот период времени на взлете VSC когда про него везде писали что это бесплатная кросcплатформенная альтернатива VS, но сами майки никогда так его не позиционировали и время показало что это два разных продукта, для разных задач, хоть и с пересекающимся функционалом.
Получение саммари к Whisper никакого отношения не имеет, это модель для перевода аудио в текст.
Если хотите чтоб саммари локально генерировался, то придется рядом с whisper разворачивать LLM (делается просто через UI, при помощи LM Studio, например) и руками уже в чат закидывать файл стенограммы с нужной инструкцией.
Выглядит интересно, довольно просто локально развертывается с подключением к lm studio. А можете вкратце описать для каких кейсов используете?