Эммм.. Ну, я как бы давно и плотно сидел на поддержке нескольких типов СЭД и в общем то, до полноценного СЭД ну ещё много чего нужно доделать. Основная суть СЭД это не фискальная регистрация и движение документов (DocFlow), а ещё и генерация документов с автоматизацией последующего движения документов согластно установленным шаблоном маршрутов и контроля созданного документа (WorkFlow) К сожалению, у нас в РФ основная идея, что нужна связка именно такого полного цикла работы с документами,облегчающая и заменяющая во многом движение бумажных документов, подзабыта. Из того с чем я последним работал подобным было DocVision. Остальные наши отечественные разработки ну весьма слабоваты, и по факту просто уберают бегатню девочек из канцелярии по подписыванию вручную составленных документов.
Автору - респект! Самое толковое что было мной прочитано по поиску работы здесь за несколько месяцев! Сам увы в активном поиске, и практически все тоже самое происходит, что описал автор. К сожалению, если не сделал задел на личные связи (увы, у меня их почти все бывший шеф замыкал на себя), потом твой опыт никому в общем то не нужен.
Точно нужны. Разгрузить думающего и опытного разработчика от рутинных мелких операций, переведя его усилия на уровень общей стратегии и планирования. И совсем не факт, что ИИ это прямая замена джуну. Как верно сказано в статье, уровень текущих инцендентов, техдолга и стратегического развития продуктов, вряд ли в ближайшее время перейдет к ИИ. А вот сменять опытного человека потом кем?
Всегда хорошо, когда что то новое в старых ЯП пытаются делать. Особенно когда это для решения проблем с современными технологиями из средств автоматизации. Помнится, я делал протокол аутентификации OAuth для своих макросов под Corel, тоже намучался. Не вчитывался в ваш код, но есть сходу небольшое предложение по оптимизации. Мне думается, лучше для файла разом подготовить буфер текстовый и и одним махом его записывать. Понятное дело, что сейчас уже нет проблем со скоростью записи во внешние файлы, но об оптимизации всё равно думать стоит, даже на очень хорошем железе. А так - пляс за статью несомненно!
По мне так самые -самые мне интересные, всегда были книги для юных читателей 30-50х годов. Вот уж где реально из "г..а и палок" сделать модели всего что тогда было актуально из науки и техники. Такой простоты изложения и доступности и реализации изложенного, сейчас во многом не хватает! С другой стороны, микросхему на кухне не соберешь и только и остается уповать, на сравнительную дешевизну компонентов из Китая
Ой, бросьте! Я сам когда то отучился на физика-теоретика, и даже окончил с красным дипломом. Вроде бы сравнительно глубоко по отношению к среднестатистическому обывателю погружался в физику на стадии учебы, но если разобраться, то даже наши профессора начинали бессильно ходить по кругу в области объяснения квантовой механики, ибо судя по всему проблема не в квантовой физике, а в том, что для понимания её механизмов, требуется несколько иное мышление, чем обладают люди. Это всего лишь попытка математически описать то, что изначально не в нашей логике.
Из коробки такое не сделать, ибо ограничение по безопасности да и вообще вся модель JS не может работать с внешними источниками данных без дополнительных костылей, типа прокси серверов для работы с такими источниками.
Ну, как минимум, у вас такое количество заявленных хабов в заголовке по разным ЯП и нет ни одной строчки, даже формального описания решения с их использованием. Ваша идея давно "витает в воздухе",и она уже во многом реализована в разного рода MCP для агентов. Поэтому, хотелось бы понимания, как конкретно вы решили в своем случае. Просто описать идею, и что она вообще решаема - для такого уровня ресурса как Хабр, в наше время как то маловато! Хочется более конкретных решений, чтобы оправдать время на чтение изложения ваших идей. Я не критикую само решение. Оно здравое, и сам к таким же идеям пришел, но пока нет времени на реализацию. И именно поэтому, очень хотелось бы ваше ноу-хао посмотреть с точки зрения человека так же готового в это окунуться, но слегонца сэкономить время и нервы, пользуясь проторенными вами путями. ЗЫ, Спасибо, что расширили в итоге статью некоторыми деталями. Есть теперь над чем подумать!
Это в теории. И даже вопрос не в адекватности, а в диаметральности взгляда на одну и туже проблему, но с разных сторон. Особенно, когда у одной стороны (менеджмента) неизвестно почему задранные ожидания для другой стороны (разрабов). В итоге получится скорее как со мной. Вроде обе стороны адекватные были, а по итогу - я работы лешился.
Процедуру прямых закупок в госструктуре так трудно обосновать, что вряд ли это вообще возможно для ситуации описанной автором. Походу - это изначально просто развод на лоха был.
Я извиняюсь конечно, но вообще не вижу в статье заявленного :
В этой статье я расскажу, как мы построили локальный RAG‑сервис, оформили его как MCP‑сервер и подключили к IDE.
По моему как, это когда описывается технологический стек, библиотеки, с чем столкнулись, какие решения и как применили в итоге. А в этой статье скорее речь вот мы какие молодцы и умеем. И толку всем остальным от такого знания?
В принципе в статье верно верно определено, но только всегда будут нюансы конкретных ситуаций. Даже если бизнесом, или маркетингом в нем, начинает заведовать бывший айтишник, он все равно неизбежно, скорее всего, придет к описанному способу выдачи задач, ибо у него наверное взгляд на конечные цели смещается. Сам недавно пострадал, можно сказать,от этого. Шеф упорно не хотел давать нормальное развернутое ТЗ. Но при этом, сам балуясь с эксперементами над ИИ, сидел и вычищал промпты по нескольку дней. Аргумент убивал, что и привело в итоге к разрыву творческих отношений: у тебя уровень эксперта, вот и сделай как я хочу. А чего шеф хочет, приходилось "вытаскивать клещами", и это и бесило и просто приводило в ступор. Наверное такой режим управления, это какой-то парадокс управленцев, и он хорошо описан где то. Но в целом - доканывает как инженера-програмиста каждый раз, как я с ним сталкиваюсь :(
Судя по вашему рассказу, все прозаичнее. Либо эти деньги были потрачены до вас, на контракте в котором ВСЁ прое..., короче потратили без результатов, а оправдать потерю денег как то надо. Либо сроки прошляпили. Или деньги потратили. Короче - в любом случае скорее всего дело там не чисто. Вот и придумали историю, в которой Главный готов был даже свои деньги под видом гранта выдать, чтобы не попасть под уголовку. Гранты - это тоже не так просто и практически всегда это конкурс, почти такой же как в прочих видах конкурсных закупок. Под него создается конкурсная комиссия. Тоже проекты надо защищать и получать контракт по гранту. Короче - вас развели. Вполне можно в суд за мошенничество подавать было. Хотя конечно - себе и дороже выйдет.
Ну, допустим не круглогодично. Там как и у нас - на охлаждение не тратятся круглый год, даже на экваторе. Но от переохлаждения вы умрете все таки быстрее, нежели от перегрева. Особенно если понимать тот факт, что организм коренных жителей настраивался тысячелетиями под такой жаркий климат. Но не спорю, для комфорта желательно иметь определенный диапазон температур в 20-25 градусов и в определенные периоды времени нужно на это тратить энергию. Но в нашем климате помимо трат на энергию для комфортного внутреннего климата в сезон, надо заложиться и на совсем другие по стоимости материалы при строительстве любого жилья, даже не жилого. Иначе все усилия на микроклимат внутри будут греть атмосферу. Это опять же - совсем иная экономика выходит, нравится вам это или нет.
Пожалуй соглашусь с вами, что RAG тут был бы целесообразнее. Но его написание и отладка, займет в целом побольше времени, ибо тут уже простым протоколом доступа к массиву данных уже не ограничишься, и требуется достаточно большой набор предварительной обработки данных, чтобы они стали полезны уже в момент работы самого агента AI. Если речь не идет о каком то более-менее статичном в развитии сервисе, то MCP решение автора вполне себе быстрая в запуске альтернатива, пусть и не столь оптимальная, каким бы мог оказаться специализированный RAG.
Конечно, могу и ошибаться, но сам проработав в крупной госструктуре почти 25лет, почти 100% могу утверждать, что любые разработки или работы на госструктуру будут только через торги. А это обязательный контракт, если выигрываешь, в котором прописываются все сроки, обязательства и т.д. для любой из сторон. Соскочить без штрафов - почти нереально. Как и не оплатить выполненные работы, если они проведены в рамках контракта - тоже! Это уже штрафы уже для заказчика. Так что описанная ситуация какая то странная, раз в ней отсутствует стадия конкурса и участия в нем.
Эммм.. Ну, я как бы давно и плотно сидел на поддержке нескольких типов СЭД и в общем то, до полноценного СЭД ну ещё много чего нужно доделать. Основная суть СЭД это не фискальная регистрация и движение документов (DocFlow), а ещё и генерация документов с автоматизацией последующего движения документов согластно установленным шаблоном маршрутов и контроля созданного документа (WorkFlow)
К сожалению, у нас в РФ основная идея, что нужна связка именно такого полного цикла работы с документами,облегчающая и заменяющая во многом движение бумажных документов, подзабыта. Из того с чем я последним работал подобным было DocVision. Остальные наши отечественные разработки ну весьма слабоваты, и по факту просто уберают бегатню девочек из канцелярии по подписыванию вручную составленных документов.
Автору - респект! Самое толковое что было мной прочитано по поиску работы здесь за несколько месяцев! Сам увы в активном поиске, и практически все тоже самое происходит, что описал автор. К сожалению, если не сделал задел на личные связи (увы, у меня их почти все бывший шеф замыкал на себя), потом твой опыт никому в общем то не нужен.
Точно нужны. Разгрузить думающего и опытного разработчика от рутинных мелких операций, переведя его усилия на уровень общей стратегии и планирования. И совсем не факт, что ИИ это прямая замена джуну. Как верно сказано в статье, уровень текущих инцендентов, техдолга и стратегического развития продуктов, вряд ли в ближайшее время перейдет к ИИ. А вот сменять опытного человека потом кем?
Всегда хорошо, когда что то новое в старых ЯП пытаются делать. Особенно когда это для решения проблем с современными технологиями из средств автоматизации. Помнится, я делал протокол аутентификации OAuth для своих макросов под Corel, тоже намучался.
Не вчитывался в ваш код, но есть сходу небольшое предложение по оптимизации. Мне думается, лучше для файла разом подготовить буфер текстовый и и одним махом его записывать. Понятное дело, что сейчас уже нет проблем со скоростью записи во внешние файлы, но об оптимизации всё равно думать стоит, даже на очень хорошем железе. А так - пляс за статью несомненно!
Да шикарный журнал был! Но у нас в станице можно было только в библиотеке достать, и то, выписывали только год или два. Очень дорогая подписка была!
По мне так самые -самые мне интересные, всегда были книги для юных читателей 30-50х годов. Вот уж где реально из "г..а и палок" сделать модели всего что тогда было актуально из науки и техники. Такой простоты изложения и доступности и реализации изложенного, сейчас во многом не хватает! С другой стороны, микросхему на кухне не соберешь и только и остается уповать, на сравнительную дешевизну компонентов из Китая
А можно ссылку где это там бесплатно? Мне любой из доступных планов весьма таки платным предлагается
Ой, бросьте! Я сам когда то отучился на физика-теоретика, и даже окончил с красным дипломом. Вроде бы сравнительно глубоко по отношению к среднестатистическому обывателю погружался в физику на стадии учебы, но если разобраться, то даже наши профессора начинали бессильно ходить по кругу в области объяснения квантовой механики, ибо судя по всему проблема не в квантовой физике, а в том, что для понимания её механизмов, требуется несколько иное мышление, чем обладают люди. Это всего лишь попытка математически описать то, что изначально не в нашей логике.
Хм... Насколько я понял (могу и ошибаться) но у автора под рекламируемым молотком подразумевался софт под Линукс, а не наоборот?
Из коробки такое не сделать, ибо ограничение по безопасности да и вообще вся модель JS не может работать с внешними источниками данных без дополнительных костылей, типа прокси серверов для работы с такими источниками.
Ну, как минимум, у вас такое количество заявленных хабов в заголовке по разным ЯП и нет ни одной строчки, даже формального описания решения с их использованием.
Ваша идея давно "витает в воздухе",и она уже во многом реализована в разного рода MCP для агентов. Поэтому, хотелось бы понимания, как конкретно вы решили в своем случае.
Просто описать идею, и что она вообще решаема - для такого уровня ресурса как Хабр, в наше время как то маловато! Хочется более конкретных решений, чтобы оправдать время на чтение изложения ваших идей.
Я не критикую само решение. Оно здравое, и сам к таким же идеям пришел, но пока нет времени на реализацию. И именно поэтому, очень хотелось бы ваше ноу-хао посмотреть с точки зрения человека так же готового в это окунуться, но слегонца сэкономить время и нервы, пользуясь проторенными вами путями.
ЗЫ, Спасибо, что расширили в итоге статью некоторыми деталями. Есть теперь над чем подумать!
Это в теории. И даже вопрос не в адекватности, а в диаметральности взгляда на одну и туже проблему, но с разных сторон. Особенно, когда у одной стороны (менеджмента) неизвестно почему задранные ожидания для другой стороны (разрабов). В итоге получится скорее как со мной. Вроде обе стороны адекватные были, а по итогу - я работы лешился.
Процедуру прямых закупок в госструктуре так трудно обосновать, что вряд ли это вообще возможно для ситуации описанной автором. Походу - это изначально просто развод на лоха был.
Я извиняюсь конечно, но вообще не вижу в статье заявленного :
По моему как, это когда описывается технологический стек, библиотеки, с чем столкнулись, какие решения и как применили в итоге.
А в этой статье скорее речь вот мы какие молодцы и умеем. И толку всем остальным от такого знания?
В принципе в статье верно верно определено, но только всегда будут нюансы конкретных ситуаций.
Даже если бизнесом, или маркетингом в нем, начинает заведовать бывший айтишник, он все равно неизбежно, скорее всего, придет к описанному способу выдачи задач, ибо у него наверное взгляд на конечные цели смещается. Сам недавно пострадал, можно сказать,от этого. Шеф упорно не хотел давать нормальное развернутое ТЗ. Но при этом, сам балуясь с эксперементами над ИИ, сидел и вычищал промпты по нескольку дней. Аргумент убивал, что и привело в итоге к разрыву творческих отношений: у тебя уровень эксперта, вот и сделай как я хочу. А чего шеф хочет, приходилось "вытаскивать клещами", и это и бесило и просто приводило в ступор.
Наверное такой режим управления, это какой-то парадокс управленцев, и он хорошо описан где то. Но в целом - доканывает как инженера-програмиста каждый раз, как я с ним сталкиваюсь :(
Судя по вашему рассказу, все прозаичнее. Либо эти деньги были потрачены до вас, на контракте в котором ВСЁ прое..., короче потратили без результатов, а оправдать потерю денег как то надо. Либо сроки прошляпили. Или деньги потратили. Короче - в любом случае скорее всего дело там не чисто. Вот и придумали историю, в которой Главный готов был даже свои деньги под видом гранта выдать, чтобы не попасть под уголовку.
Гранты - это тоже не так просто и практически всегда это конкурс, почти такой же как в прочих видах конкурсных закупок. Под него создается конкурсная комиссия. Тоже проекты надо защищать и получать контракт по гранту. Короче - вас развели. Вполне можно в суд за мошенничество подавать было. Хотя конечно - себе и дороже выйдет.
Ну, допустим не круглогодично. Там как и у нас - на охлаждение не тратятся круглый год, даже на экваторе.
Но от переохлаждения вы умрете все таки быстрее, нежели от перегрева. Особенно если понимать тот факт, что организм коренных жителей настраивался тысячелетиями под такой жаркий климат. Но не спорю, для комфорта желательно иметь определенный диапазон температур в 20-25 градусов и в определенные периоды времени нужно на это тратить энергию. Но в нашем климате помимо трат на энергию для комфортного внутреннего климата в сезон, надо заложиться и на совсем другие по стоимости материалы при строительстве любого жилья, даже не жилого. Иначе все усилия на микроклимат внутри будут греть атмосферу. Это опять же - совсем иная экономика выходит, нравится вам это или нет.
Пожалуй соглашусь с вами, что RAG тут был бы целесообразнее. Но его написание и отладка, займет в целом побольше времени, ибо тут уже простым протоколом доступа к массиву данных уже не ограничишься, и требуется достаточно большой набор предварительной обработки данных, чтобы они стали полезны уже в момент работы самого агента AI. Если речь не идет о каком то более-менее статичном в развитии сервисе, то MCP решение автора вполне себе быстрая в запуске альтернатива, пусть и не столь оптимальная, каким бы мог оказаться специализированный RAG.
Не стоит этого делать. Там все таки активно образуется пар, и значит повышается давление. А в герметичном сосуде это чревато взрывом
Конечно, могу и ошибаться, но сам проработав в крупной госструктуре почти 25лет, почти 100% могу утверждать, что любые разработки или работы на госструктуру будут только через торги. А это обязательный контракт, если выигрываешь, в котором прописываются все сроки, обязательства и т.д. для любой из сторон. Соскочить без штрафов - почти нереально. Как и не оплатить выполненные работы, если они проведены в рамках контракта - тоже! Это уже штрафы уже для заказчика. Так что описанная ситуация какая то странная, раз в ней отсутствует стадия конкурса и участия в нем.