Всем привет!

Недавно возникла необходимость создать AI-ассистента, обученного искать и выдавать информацию из базы знаний, предоставленных заказчиком.

В этой статье мы рассмотрим процесс создания MVP такого ассистента. Мы загрузим в него файлы, зададим инструкции, привяжем все к Telegram-боту и будем обрабатывать запросы пользователей.

Для создания ассистента будем использовать функциональность OpenAI Assistants API с помощью сторонних прокси-сервисов.

Все это напишем на Go, а код, готовый к запуску и компиляции, будет доступен в конце статьи.

Приятного чтения!

WaitGroup — это, по сути, способ дождаться, пока несколько горутин закончат свою работу. Мы начнем с основ, а затем разберемся, как это устроено под капотом.

Прошло уже более года с тех пор как я написал статью - Анонимная сеть в 200 строк кода на Go. Пересмотрев её однажды осенним вечером я понял насколько всё в ней было ужасно - начиная с самого поведения логики кода и заканчивая его избыточностью. Сев за ноутбук и потратив от силы 20 минут у меня получилось написать сеть всего в 100 строк кода, используя лишь и только стандартную библиотеку языка.

Жизнь – это вечная спираль, где всё идёт по кругу, но с каждым витком становится лучше. Ещё 20 лет назад я писал веб-приложения на Perl + Template Toolkit 2, генерируя HTML на стороне сервера. Время шло, и веб-разработка разделилась на две половины: фронтенд и бэкенд, а между ними API. Со временем я переключился с Perl на Go для бэкенда и AngularJS, а потом и Vue для фронтенда. В таком стеке я создал несколько проектов, включая HighLoad.Fun. Писать API и генерировать клиентскую библиотеку на TypeScript было удобно, а Vue-приложение деплоилось как SPA. Всё вроде бы шло хорошо... до тех пор, пока не пришла необходимость внедрить SSR для SEO. Тут начались проблемы: нужно было поднять NodeJS сервер для выполнения SSR, который должен ходить на Go сервер за данными, думать о том, где в данный момент выполняется код, на сервере или в браузере и писать и писать бессмысленный код перекладывающий данные.

Тогда я встал перед выбором: либо отказаться от Go на бэкенде, либо отказаться от Vue на фронтенде. Для меня выбор был очевиден: я остался с Go.

Генерация HTML на Go, в общем-то, не проблема: можно использовать готовые шаблонизаторы, вручную писать контроллеры и настроить WebPack для сборки статики. Но всё это долго и неудобно. А главное – я люблю писать программы, но ненавижу писать код. И тогда я задался целью: создать инструмент, который облегчит мне жизнь и будет автоматически решать большую часть задач за меня.

Мне нужен был генератор, который бы:

* Превращал Vue-подобные шаблоны в Go-код с типизированными переменными, позволяя ловить ошибки на этапе компиляции.

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

* Собирал и подключал только нужные JS и CSS файлы из лежащих рядом с шаблонами TypeScript и SCSS файлов.

* Поддерживал переменные, выражения, условия и циклы в шаблонах, как во Vue.

* Объединял шаблоны из подпапок по принципу Vue-тега <router-view/>.

* Автоматически маршрутизировал страницы, поддерживая динамические параметры.

И главное – всё это должно работать в автоматическом режиме: изменения в исходном коде автоматически пересобираются и перезапускаются без лишних усилий.

После ряда экспериментов и нескольких ночей мне это кажется удалось. Под катом – подробный туториал, как разрабатывать быстрые и удобные сайты с помощью GoSSR.

Все мы знаем: Go — это классный язык программирования.
Простота, ясность, скорость компиляции — мечта разработчика.
Но вот одна вещь может довести до белого каления — это обработка ошибок.
В отличие от языков вроде Java или Python, где ошибки обрабатываются с помощью конструкции try-catch, Go предпочитает явный подход: большинство функций возвращают ошибку в виде второго значения, и разработчик обязан проверять её после каждого вызова.

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

if err != nil {
    return err
}

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

Методисты курсов по английскому в Практикуме объяснили разницу между CV и resume — в США, Европе и Великобритании эти слова означают разные вещи. А ещё поделились общим алгоритмом составления «резюме» и посоветовали, как грамотно заполнить все разделы.

Привет! Меня зовут Бальцер Вадим, я QA-инженер в команде android направления Банки.ру. Сегодня поделюсь нашим опытом внедрения автотестов обратной совместимости и интеграции их в CI. 

В материале расскажу: 
1) зачем нашей команде понадобились автотесты для контроля обратной совместимости API, почему мы выбрали Postman CI.
2) с чего начали: базовые вещи + полезные советы для начинающих.
3) есть ли жизнь за гранью проверок схемы.
4) CI и интеграция с ТестОпс.
5) к чему пришли и какие перспективы видим.

Также добавлю примеры примеры кода и небольшие советы, которые могут пригодиться, если вы еще только присматриваетесь к Postman как к инструменту автоматизации проверок API.

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

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

Работа в новой компании — это всегда увлекательно. Я осознал, что даже если какой-то аспект кажется простым, например, SQL-транзакции, его легко упустить из виду.

SQL кажется чем-то, что мы все хорошо знаем, и мало чем может удивить. (Ему уже 50 лет!) Возможно, пришло время пересмотреть подходы, так как мы уже прошли фазу хайпа по поводу NoSQL, и снова возвращаемся к “используйте просто Postgres”, а иногда и к “SQLite тут за глаза”.

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

Основной принцип многослойной архитектуры заключается в разделении критически важных частей кода (логики) от деталей реализации (например, SQL-запросов). Одним из способов достижения такого разделения является паттерн «Репозиторий». Однако, наиболее сложным аспектом такой архитектуры является обработка транзакций.

Существуют различные шаблоны проектирования облачных сервисов. Про тот же Sidecar или Ambassador, я думаю, слышали многие. Шаблоны предназначены для решения определенных задач и те два шаблона, о которых речь пойдет в сегодняшней статье, тоже нужны для конкретной задачи — работы с базами данных.

СУБД является неотъемлемой частью хоть сколько‑нибудь серьезного современного приложения. Соответственно, при проектировании приложения может возникнуть вопрос, как лучше сервисам взаимодействовать с базой данных: предоставляя общий доступ к одной базе или же у каждого микросервиса должна быть своя база данных. Мы рассмотрим два шаблона, предназначенных для решения данной задачи — это Shared database и Database per Microservice. Начнем с Shared database.

У меня есть приятель. Он венгр, по профессиональной надобности учит русский. Когда мы познакомились, он гордо предъявил мне 1-ю книгу, которую начал читать на русском. Там была…  (барабанная дробь!) сказка про лисичку.

Сюжет я не помню, но слова, которые он перевел и выписал, навсегда остались в моей памяти – печка, колодец, метла, ведро и глаголы типа «затопить». Очень полезная лексика, не так ли?

Я не знаю, кто придумал, что взрослым людям, которые только начали учить язык, надо читать детские книги. Ну типа язык простой (царевич, лягушка, терем), и сюжет увлекательный – вам же очень хочется перечитать «Приключения Тома Сойера» в 30 лет, правда?

На самом деле, с детскими книжками придется изрядно помучиться – обычно довольно сложная грамматика, и куча слов, которые обычно учат на высоких уровнях. А польза от всех этих белочек и лягушек – сомнительная.

Некоторые отчаянные головы берутся сразу за Чарльза нашего Диккенса и Джейн Остин. Как будто с конца 19-го века американские, британские, австралийские авторы ничего достойного не написали. Сами носители языка считают Диккенса сложным автором, и понятно, таким языком уже никто не говорит.

ДИСКЛЕЙМЕР: все, что я скажу дальше, написано для тех, кто однажды начал читать в оригинале, перевел 1-ю страницу и бесславно дезертировал. Если вы получаете удовольствие от английской классики, ничего полезного из этого поста вы не узнаете.

А что читать, если

...вы только начали учить язык

Прогулите Graded Readers, и вам откроется новый увлекательный мир. Graded Readers – это такие тоненькие книжки, специально для тех, кто только начинает учить язык. Они называются graded, потому что поделены на уровни.

Если среди физиков настоящей легендой безумных жизненных историй был Ричард Фейнман, то среди математиков и инвесторов этот титул должен по праву принадлежать Эдварду Торпу. Чувак смог не только обуть казино сразу в двух считавшихся ранее «непобедимыми» играх, но и заработать $800 млн на фондовом рынке благодаря идее, достойной Нобелевки.

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

Не секрет, что чем плотнее вы окружите себя английским языком, тем быстрее начнёте его понимать и использовать в обычной жизни. Но если перестараться, то можно надолго отбить желание учить что-то новое. Как не заскучать и не перенапрячься в процессе изучения языка? Мы попросили поделиться полезными лайфхаками методиста и райтера курсов английского в Яндекс Практикуме Дарию Василенко.

Привет! Меня зовут Денис, я — разработчик ПО SEDMAX. Это промышленное ПО для сбора и визуализации данных в энергетике. Как и у всех, у нас бывают баги. Мне бы хотелось поделиться опытом в поиске таких багов, а также порассуждать на тему того, что необходимо было сделать, чтобы баг не появился. У нас серверная часть написана на go в виде некоторого множества сервисов, поэтому специфика большинства багов будет асинхронное взаимодействие, а код примеров представлен на go.

В прошлой статье были сделаны следующие выводы:

Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?

Меня зовут Никита Галушко. Я старший программист-разработчик в отделе высоконагруженных систем и оптимизации ВКонтакте. В статье поделюсь, какие хитрости помогут использовать Go на полную мощность.

Приложению cara.app пришёл счет от Vercel на 96280$. Многие стартапы начинают с Vercel и Firebase, затем из нежелания платить гуглу уходят на свои сервера

Поговорим с нюансами про стэк технологий и оценим усилия на миграцию на свои сервера. Разберём на примере Go с k8s и инфраструктурой мониторинга, но без Firebase (Github)

В Golang (да в принципе во всех ЯП) управление памятью и эффективное использование ресурсов — основа создания высокопроизводительных приложений. Одним из важных инструментов, который помогает справляться с этой задачей, является сборщик мусора (на англ garbage collection). Встроенный сборщик мусора Go выполняет свою работу довольно хорошо, но иногда требуется более тонкая настройка, чтобы соответствовать специальным требованиям потребностям конкретного приложения.

Здесь нам и помогут кастомные сборщики мусора.

Часто задается вопрос: как эффективно и быстро обработать огромные объемы информации? Ответом на этот вызов стала концепция MapReduce, разработанная в недрах Google.

MapReduce — это парадигма программирования, созданная для обработки и генерации больших объемов данных с использованием параллельных распределенных алгоритмов. Основная фича проста: сначала данные разбиваются на небольшие части (фаза Map), а затем результаты этих частей агрегируются в финальный результат (фаза Reduce).

Всем привет, на связи Вадим Макеров, бэкенд‑разработчик iSpring. Успешная воспроизводимая сборка проекта является критическим фактором в поддержке и развитии проекта. При большом количестве проектов и технологических стеков гарантировать воспроизводимость сборки — «собралось однажды, соберется всегда» — сложнее.

О том, как реализовать идемпотентность сборки, я рассказывал в рамках митапа в офисе iSpring в 2023 году. Эта статья — текстовая версия моего доклада.

// гофер пытается найти логику среди обработки ошибок
+-------+-------+-------+-------+-------+-------+
|       |  err  |       |  err  |       |  err  |
|  ,_,,,        |       |       |       |       |
| (◉ _ ◉)       |       |       |       |       |
|  /)  (\               |       |       |       |
|  ""  ""               |       |       |       |
+       +-------+       +-------+       +-------+
|       |  err          |  err  |       |  err  |
|       |               |       |       |       |
|       |               |       |       |       |
+-------+       +-------+       +-------+       +
|  err  |               |  err                  |
|       |               |                       |
|       |               |                       |
+       +-------+       +       +-------+       +
|       |  err  |               |  err  | logic |
|       |       |               |       |       |
|       |       |               |       |       |
+-------+-------+-------+-------+-------+-------+

Я пишу на Go несколько лет, в Каруне многие вещи сделаны на нём; язык мне нравится своей простотой, незамысловатой прямолинейностью и приличной эффективностью. На других языках я писать не хочу.

Но сорян, к бесконечным if err != nil я до конца привыкнуть так и не смог.

Да-да, я знаю все аргументы: явное лучше неявного, язык Go многословен, зато понятен, и всё такое. Но, блин, на мой взгляд Го-вэй Го-вэю рознь.