Мне очень нравится LM Studio, так как она позволяет локально запускать ИИ модели. Что позволяет сохранить приватность того о чем ты беседуешь с ИИ. Но по сравнению с коммерческими онлайн моделями, LM Studio не умеет ходить в интернет "из коробки". Те модели не могут использовать актуальную информацию из Интернета для ответов на вопросы.

Не так давно в LM Studio было добавлено возможность подключать MCP-сервера к моделям. Самое первое, что я сделал это, написал небольшой MCP-сервер, который позволяет извлекать текст из URL-адреса. Также может извлекать ссылки, которые есть на странице. Это дает возможность в запросе к ИИ указать адрес и попросить извлечь текст оттуда или ссылки, что бы использовать при ответе.

Что бы это все работало, для начала создаем pyproject.toml в папке mcp-server.

Всем привет! Я пришёл из экосистемы Rust и недавно начал работать в Python. Я люблю Rust за безопасность и скорость, но влюбился в Python за простоту и быструю разработку. Это вдохновило меня создать что-то полезное для сообщества Python: FastPy-RS — библиотеку часто используемых функций, которую можно вызывать из Python, а реализация внутри написана на Rust. Цель — обеспечить высокую производительность и надёжность. Хотя многие Python-библиотеки используют C для ускорения, такой подход может нести риски безопасности.

Я решил сделать уникальную колоду карт Таро. Заказывать их у фриланс-художников дорого: каждая карта стоит от 5 USD, так что для полной колоды из 78 карт это выходит 390 USD. Перебрав разные генераторы изображений, я остановился на модели GPT-Image-1 от OpenAI, поскольку она выдаёт максимальное качество и минимальный процент ошибок. В среднем генерация одной карты занимает около минуты. Создание одной колоды обошлось мне в $25. В итоге я сгенерировал три колоды с уникальными стилями и потратил на это в общей сложности 75 USD.

Думаю, все сталкивались с тем, что языковая модель отказывается отвечать на какие-то вопросы. К счастью, в интернете есть опубликованные так называемые abliterated модели, которые не имеют цензуры и отвечают на любые вопросы. Хоть такую модель можно скачать (16 ГБ файл), запустить её у себя на компьютере достаточно сложно. Проблема в том, что у многих нет видеокарты за 1000 $ или дорогого Apple Mac компьютера последнего поколения с чипом M1 и выше. И многие знакомые, узнав о возможности получить ИИ без цензуры, хотят это попробовать и просят помочь им инструкциями, как это сделать, не покупая видеокарту или Apple Mac компьютер. В итоге я решил выложить инструкцию, как это сделать за сущие копейки через почасовую аренду видеокарты.

Идея создания этого пет-проекта возникла из желания написать собственного ИИ-агента. Я сформулировал для себя минимальные технические требования: агент должен иметь несколько состояний, уметь запускать тулзы и использовать RAG для поиска ответов на вопросы.

В итоге возникла идея написать персонального телеграм-ИИ-бота, который умеет запоминать нужную мне информацию, и когда мне надо — я могу его спросить, что он запомнил. Что-то вроде блокнота, только это будет ИИ-блокнот, который умеет отвечать на вопросы. В дополнение я решил добавить в него функцию, чтобы он мог запускать команды на сервере — причём команды, описанные человеческим языком, он будет переводить в команды для терминала.

Изначально я думал использовать LangChain. Очень хороший инструмент — позволяет подключать векторные базы данных, использовать различные LLM как для инференса, так и для эмбеддинга, а также описывать логику работы агента через граф состояний. Можно вызывать уже готовые тулзы. В целом, на первый взгляд всё выглядит удобно и просто, особенно когда смотришь типовые и несложные примеры.

Но, покопавшись немного глубже, мне показалось, что затраты на изучение этого фреймворка не оправдывают себя. Проще напрямую вызывать LLM, эмбеддинги и Qdrant через REST API. А логику работы агента описать в коде через enum, описывающий состояния, и делать match по этим состояниям.

К тому же LangChain изначально написан на Python. Я хотел бы писать на Rust, а использовать Rust-версию LangChain — сомнительное удовольствие, которое обычно упирается в самый неподходящий момент: что-то ещё не было переписано на Rust.

Для изучения нового языка программирования я использую следующий подход. Сначала я читаю учебник по этому языку программирования, в котором объясняются синтаксис, идиомы, философия и принципы работы языка. После этого я пишу небольшой пет-проект на этом языке программирования. На пет-проекте я немного практикуюсь с новым языком, с его стандартными библиотеками и популярными фреймворками.

Чтобы погрузиться сильнее в язык, вместо пет-проекта я начинаю писать свои библиотеки для работы с базами данных (ORM), JSON, акторами, MVC веб-фреймворком, логированием и т.д. Библиотеки, которые вряд ли будут кому-то нужны, но они помогут мне лучше понять язык программирования. На удивление, с языком Rust я добрался до написания своего веб-сервера. Раньше такого не было. Думаю, это из-за того, что Rust — это язык системного программирования и грех на нём не попробовать заняться оптимизацией перформанса.

В итоге я столкнулся с тем, что Rust не имеет аналогов Nginx, Lighttpd, Caddy, HAProxy, Apache, Tomcat, Jetty и т.д. Все эти веб-сервера написаны на C, Go, Java и т.д. Имеются только веб-фреймворки: Actix, Axum, Rocket, Hyper и т.д.

В целом я прикинул, что обычно я использую Nginx для следующих целей:

1. TLS для доменов

2. Проксирование запросов на бэкэнд

3. Раздача статических файлов

В итоге решил написать свою реализацию веб-сервера на Rust.

Я начал работать над проектом Shiva с первого коммита в марте 2024 года, стремясь создать универсальный инструмент на Rust для парсинга и конвертации документов. За несколько месяцев проект значительно расширился, добавив поддержку множества форматов файлов, включая HTML, Markdown, простой текст, PDF, JSON, CSV, RTF, DOCX, XML, XLS, XLSX, ODS и Typst. Shiva — это проект с открытым исходным кодом, и его репозиторий доступен на github.com/igumnoff/shiva.

Цель проекта — предложить альтернативу таким известным инструментам, как Apache Tika, написанный на Java, и Pandoc, разработанный на Haskell. Эти инструменты уже давно стали стандартом для разработчиков, работающих с документами. Однако я надеюсь, что Shiva сможет предложить более простое и эффективное решение, которое сможет справляться с растущим разнообразием и сложностью цифровых документов. Проект развивается быстро, хотя впереди еще много работы, но мне радостно наблюдать за прогрессом.

Я хочу выразить огромную благодарность всем, кто помогал добавлять поддержку новых форматов. Ваш вклад был неоценим.

Буду рад, если кто-то заглянет в репозиторий, оставит отзыв или внесет свой вклад. Сообщество открыто для идей и совместной работы, чтобы продолжать развивать возможности Shiva.

Я работал над созданием инструмента под названием rustsn, который позволяет генерировать, компилировать и тестировать код с использованием LLM (Large Language Models). Изначально идея заключалась в том, чтобы автоматизировать процесс написания небольших фрагментов кода — так называемых сниппетов — для разных языков программирования на основе объяснений, предоставленных пользователем. Этот инструмент стал развиваться и обрастать новыми возможностями, такими как генерация полного кода для приложений и объяснение существующего кода на основе векторных представлений (эмбеддингов).

Когда я только начинал работу над rustsn, основной задачей было добиться того, чтобы пользователь мог, например, просто описать словами, какую функцию ему нужно написать, а система автоматически генерировала бы рабочий код. Я начал с Rust, поскольку этот язык обладает мощными возможностями для работы с типами и тестированием, что делает его идеальным для написания безопасного и производительного кода. Позже я добавил поддержку других языков, таких как JavaScript, Python, и TypeScript.

Этот инструмент стал гораздо больше, чем просто генератор кода. Например, я добавил команду ask, которая позволяет получать объяснение к существующему коду вашего проекта. Для этого используется специальная модель, которая анализирует исходники и находит наиболее релевантные файлы на основе вашего вопроса.

В ближайшее время я планирую значительно расширить функционал rustsn. Первое, что я хочу сделать — это интегрировать Docker, чтобы пользователи могли запускать инструмент не только на хостовой машине, но и в контейнерах. Это упростит развертывание и использование инструмента на различных платформах, обеспечив стабильность окружения.

Несколько дней назад я опубликовал статью Создание инструмента генерации кода с помощью Rust и локальных LLM от Ollama.

Проект Rustns призван упростить жизнь разработчикам Rust за счет автоматизации утомительных задач. Мой инструмент генерирует фрагменты кода Rust из объяснений пользователя, компилирует их, разрешает зависимости, генерирует тесты.
Изначально проект задумывался как универсальное решение для генерации кода для самых популярных языков программирования, включая Java, Python и TypeScript. Я стремился создать инструмент, который бы облегчил работу разработчиков, предоставляя возможность генерировать код сразу на нескольких языках. Однако, приступив к реализации мультиязычности, я столкнулся с серьёзными трудностями.

Попытка унифицировать код для различных языков оказалась куда более сложной задачей, чем я ожидал. Каждый язык программирования имеет свои особенности, что значительно усложняет код и поддержку всех этих языков в одном проекте.

В итоге я пришёл к выводу, что нужно сконцентрировать свои усилия на одном языке программирования. В моём случае это Rust, на котором был написан проект, генерирующий Rust-код.

Вот упрощенная диаграмм работы проекта:

Это реакция на выпуск ChatGPT o-preview. Попытка добавить логику в LLM с открытым исходным кодом, которые можно запустить дома на скромном GPU или даже на CPU

Сейчас я работаю над инструментом на основе Rust, который автоматизирует генерацию, компиляцию и тестирование кода с использованием больших языковых моделей (LLM). Идея заключается в том, чтобы взаимодействовать с LLM для генерации кода на основе предоставленных пользователем объяснений, компилировать код, разрешать зависимости и запускать тесты, чтобы убедиться, что все работает так, как ожидается.

Я хотел бы оптимизировать процесс кодирования функций на основе описаний на естественном языке. Я хотел создать систему, в которой я мог бы ввести объяснение того, что должна делать функция, и чтобы инструмент обрабатывал все остальное от генерации кода до тестирования.

Работа инструмента начинается с того, что запрашивает у пользователя объяснение функции, которую он хочет создать. Затем он взаимодействует с LLM для генерации кода функции, компилирует его и проверяет на наличие ошибок компиляции. Если ошибки обнаружены, инструмент пытается их устранить, возможно, путем добавления зависимостей или переписывания кода. После успешной компиляции кода он генерирует тесты для функции, запускает их и снова обрабатывает любые ошибки, итеративно улучшая код или тесты.

Первый шаг — получить объяснение от пользователя:

Как известно, у больших языковых моделей (LLM) существуют ограничения по размеру контекстного окна. При постановке вопроса часто невозможно вставить весь исходный текст, что требует объединения кода из разных файлов в одном месте.

В связи с этим я разработал скрипт, который минимизирует исходный код проекта путем удаления пробелов, табуляций, комментариев и тестовых функций. Скрипт позволяет собрать все или выбранные файлы проекта в одном месте.

Для использования просто запустите скрипт в директории вашего проекта, чтобы сгенерировать минимизированный файл out.txt, содержащий оптимизированный код, готовый для использования с крупными языковыми моделями.

Перед запуском скрипта отредактируйте следующие массивы в соответствии с потребностями вашего проекта: folders_to_ignore, extensions_to_search, filenames_to_search, comment_chars и stop_words.

Пример конфигурации для проекта на Rust (включение всех файлов *.rs в out.txt):

Последнее время достаточно популярна "async/await" концепция в Rust. Безусловно для подавляющего большинства задач это лучший вариант. Так как она ориентирована на то что система, которая обрабатывает сетевые запросы, например сталкивается с блокировкой ввода/вывода к базе данных. В результате лучшим решением будет использование "async/await", так как он позволяет использовать один поток для обработки множества запросов. Если функция "async" не может быть завершена например из-за ожидания ввода-вывода, она может отдать управление в точке ее вызова "await". И "executor" например "Tokio" может переключиться на другую задачу.

В целом мне очень нравится концепция Акторов в асинхронном программировании. Низкоуровневое программирование с использованием очередей сообщений и обработчиков сообщений не позволяет мыслить в терминах высокоуровневых абстракций. Акторы позволяют абстрагироваться от низкоуровневых деталей. Другими словами, Акторы посылают сообщения друг другу. А то, что Акторы на самом деле работают на очередях сообщений, нам не важно. Это скрыто 'под капотом'

Во время изучения Tokio, я решил написать свой проект для модели Акторов. Как раз низкоуровневая часть Tokio позволила это сделать. Так появилась библиотека Gabriel2.

Примерно 10 месяцев назад у меня получилась первая версия библиотеки. Первым делом я определил типизированную структуру ссылки на Актора:

Примерно 8 месяцев назад я написал на Rust pet-проект, который пытается быть подобием Hibernate в экосистеме Java. Я даже опубликовал его в качестве Open Source, но получил негативный отзыв и удалил его с GitHub.

Сейчас я решил вернуться к этому проекту, но подойти к нему с другой стороны. Я бы хотел услышать идеи по проекту от опытных разработчиков на Rust. Что в моем проекте сделано не в идиоматическом стиле Rust и т.д. и т.п. В общем, хочется получить чек-лист того, что в проекте не так и как это исправить.

Год назад возникла идея переписать весь Java-бекенд на Rust, который я уже несколько лет разрабатываю и поддерживаю. Я нашёл все аналоги библиотек и фреймворков из мира Java в экосистеме Rust:

Идея проекта возникла у меня во время работы над проектом поисковика документов. Существует такая библиотека, как Apache Tika, написанная на Java, которая умеет парсить документы различных типов. Чтобы мой поисковик работал, он должен уметь извлекать текст из документов разных типов (PDF, DOC, XLS, HTML, XML, JSON и т. д.). Сам поисковик я писал на Rust. Но, к сожалению, в мире Rust нет библиотеки, которая умела бы парсить документы всех типов.

Первый крупный рост цены биткона был связан с тем, что люди о нем узнавали и начинали изучать. Главные идеи были в том, что он децентрализован, защищен криптографически, и ограничена эмиссия, что его превращает в цифровое золото. Все стали его воспринимать с надеждой на то, что он станет в будущем платежным средством и средством накопления. 
 


Следующий крупный рост цены биткоина был вызван интересом к эфиру и его смарт контрактам, на основе которых проводили ICO. Как результат, следующая партия инвесторов погружалась в мир криптовалют и узнавала в том числе о биткоине. Это первая эра роста альткоинов, опережающая рост биткоина. 
 


Дальнейший крупный рост цены биткоина был вызван ажиотажем вокруг незаменимых токенов NFT на базе смарт контрактов. В то же время были запущены стейбл коины на USDC и USDT, которые явно конкурировали с биткоином как платежное средство, имеющие большое преимущество в скорости транзакции и стабильности курса почти 1 к 1 к USD. Как результат, произошел новый приток инвесторов и пользователей на крипторынок.

Текущий рост биткоина обоснован запуском Bitcoin ETF на американском рынке, совпавшим с ближайшим халвингом. Менеджерам легко рекомендовать покупку биткоина через ETF клиентам, так как халвинг меньше, чем через два месяца.

На будущий курс биткоина могут повлиять:

Масштабируемость: одним из ключевых технических вызовов для биткоина является масштабируемость сети. Решения второго уровня, такие как Lightning Network, предлагают значительное увеличение количества транзакций в секунду, при этом снижая комиссии. Успешное внедрение и адаптация этих технологий могут существенно повысить утилитарную ценность биткоина как средства платежа. 
 


Для меня загадка, почему программисты не могут оценить бизнес компании, в которую устраиваются. Почему у них прямо разрыв между тем, что компания должна быть прибыльной ежегодно, и тем, что она ему платит и повышает зарплату из-за этого, чтобы удержать программиста.

Я рад сообщить, что вышла новая версия моей Rust-библиотеки для объектно-реляционного отображения - Ormlib 1.0.1. В этой версии было проделано много работы по улучшению архитектуры библиотеки.

В предыдущей версии 0.3.3, Ormlib работал только с базой данных SQLite. Это ограничивало сферы применения библиотеки. В версии 1.0.1 была проделана большая работа по рефакторингу кода, чтобы абстрагировать ее от конкретной реализации СУБД.

После рефакторинга я использовал механизм "features", который позволяет компилировать Ormlib либо с поддержкой SQLite, либо с поддержкой MySQL.

Приложения на Rust часто используют асинхронные библиотеки, такие как Tokio и Actix. Эти библиотеки предоставляют инструменты для асинхронного ввода-вывода и параллельных вычислений и т.д. Однако иногда возникают проблемы при совместном использовании разных асинхронных библиотек.

Сегодня я хочу поделиться с вами опытом решения одной из распространенных проблем при работе с библиотеками Tokio и Actix. Конкретно, мы рассмотрим ошибку "error: future cannot be sent between threads safely", которая может возникнуть, когда вы пытаетесь использовать клиент Actix внутри асинхронной функции, запущенной с помощью Tokio. Я расскажу вам, как преодолеть эту проблему.