Казалось бы, в посгресе и так есть неплохой полнотекстовый поиск (tsvector/tsquery), и вы из коробки можете проиндексировать ваши тексты, а потом поискать по ним. Но на самом деле это не совсем то, что нужно — такой поиск работает лишь по чётким совпадениям слов. Т.е. postgres не догадается, что "кошка гонится за мышью" — это довольно близко к "котёнок охотится на грызуна". Как же победить такую проблему?

TLDR:

1. Преобразовываем наши тексты в наборы чисел (векторы) при помощи API openAI.
2. Сохраняем векторы в базе с помощью pgvector.
3. Легко ищем близкие друг к другу векторы или ищем их по вектору-запросу.
4. Ускоряем индексами.

Как не умереть от рабочей рутины и не потерять фокус между десятками ежедневных задач? Как по максимуму использовать почту, календарь, мессенджер и браузер?
Читайте мини-гайд и берите на заметку!
P.S. ТОП 8 неудачных прыжков на грабли в комплекте

Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.

Т.е., таблица изначально выглядит так:

CREATE TABLE coupons (
    id  bigint primary key generated by default as identity,
    user_id bigint not null,
    created_at timestamp not null,
    valid_until timestamp not null
)

Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.

Т.е., таблица изначально выглядит так:

CREATE TABLE coupons (
    id  bigint primary key generated by default as identity,
    user_id bigint not null,
    created_at timestamp not null,
    valid_until timestamp not null
)

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

Какие подходы к управлению временем вы сейчас используете? Готовы ли вы сказать, что у вас чёткая система по управлению вашими рабочими задачами?

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

Идея упростить или абстрагировать код с помощью ORM, возможно, имеет очень ограниченный контекст применимости. По сути ORM хорош для приложений уровня простого CRUD, а дальше начинает только мешать. А CRUD-приложений в реальной жизни очень мало.

Проблемы

1. При использовании ORM мы обычно прописываем в коде сущности и их взаимосвязи, и по сути это — проектирование БД ещё раз (дублирование логики!) прямо в коде.
2. Борьба с проблемами производительности никуда не денется всё равно, как ни абстрагируй. Ты просто не можешь не знать, что у тебя под капотом происходит. Какие там делаются джойны и группировки.
3. Язык запросов в виде цепочки объектов и методов читается хуже, чем SQL, по сути это — особый язык, который надо учить. За себя скажу, что когда писал на PHP (Laravel), длинные запросы на Eloquent меня иногда изумляли своей сложностью чтения:

Сборная солянка из существующих best practices по работе с Grafana и немного с Prometheus, проверенных мной лично. Можно просто положить в закладки — когда-нибудь да пригодится.

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

В Go 1.20 сделали возможность сбилдить приложение с флагом cover

go build -cover

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

Это, конечно, было сделано для интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но, вероятно, это можно попробовать использовать и по-другому:

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

Так можно найти недовыпиленный легаси-код, старые эндпоинты API, которые давно никому не нужны, малозначимые проверки if err != nil и прочее. Как минимум, на это интересно посмотреть, можно найти что-нибудь удивительное.

Disclaimer: разумеется, сбор статистики создает какой-то оверхед, поэтому подойдёт точно не всем. Как вариант, можно пустить туда небольшую часть трафика.

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

А что делать, если прямо сейчас у вас нет ни времени на разработку сложных подходов, ни приблизительного понимания, как долго живёт ваш среднестатистический клиент, а задача от бизнеса дать какие-то рекомендации есть?

Меня зовут Артём, я антифрод-аналитик в Каруне, и в данной статье мы рассмотрим достаточно простой подход, с помощью которого можно решить обозначенную проблему. Если вы скажете, что антифрод решает абсолютно другой спектр задач, то будете абсолютно правы. Однако во время работы с одним из проектов при переосмыслении использованного алгоритмического стека в нём, мы пришли к выводу, что отдельные небольшие кусочки этого стека вполне могут подходить и для решения других задач. На базе нашего опыта расскажу, как с помощью байесовского моделирования и библиотеки PyMC3 можно получить примерную картину о том, как долго ваш клиент должен быть неактивным, чтобы считать его отточником. Это может помочь ответить на базовые вопросы бизнеса и подготовиться к реализации более точных и качественных моделей (если это потребуется).

Вы когда-нибудь приходили на позицию руководителя в новую для вас команду? 

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

Вас ждет небольшой Cookbook по непростым ситуациям и вариантам их решения. 

Упор делаю на процессы и людей — именно эти 2 “стула” вам предстоит осилить.

// теперь в Go так можно!
slices.Contains(s, v)

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

Однако для стандартной библиотеки Go это было по-настоящему царским подарком. Появились новые стандартные обобщенные функции, и, отстоявшись в экспериментальном репозитории golang.org/x/exp, теперь появятся в Go 1.21. Релиз буквально через месяц.

TLDR: появилось множество функций по работе со слайсами, мапами, а также новый логгер с (почти) всеми нужными фишечками.

Лично для меня знаковым событием стало появление возможности поиска элемента в слайсе и получение ключей мапы, потому что ну давно пора, 10 лет языку.

Но давайте обо всём по порядку.

О чем и для кого статья?

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

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

Привет, меня зовут Мария, я работаю в Каруне неунывающим экспериментатором чата GPT, ну а вообще UX-писателем. В предыдущей статье я попыталась устроиться Middle Full-Stack разработчикам только с помощью чата GPT. Результаты моего эксперимента можно почитать в этой статье.

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

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

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

На конференциях эта тема (монолит vs микросервисы) обсуждается с завидной регулярностью, но обычно в техническом ключе. Кто-то любит консистентность монолита, кто-то гибкость микросервисов, какие-то инструменты удобнее, какие-то нет.

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

Поехали.

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

Одна команда

Когда команда одна, не очень большая (two pizza team), то никто никому не мешает. Код ревью, рефакторинг, деплой проходят быстро и весело. Бизнес сфокусирован на цели и работает как единое целое. Целью, кстати, зачастую является проверка гипотезы, нужен ли вообще этот проект кому-то или нет.

У нас было 3 темы, 15 команд, 6 сочных заданий, 9 часов плотного хакатонинга с перерывом на обед, заполненный 10+ проектами на 2 квартала вперёд роадмап, и ноль программирования. Мы называли это Карунатон.

Давайте сразу черкану, что даст вам эта статья, и зачем читать её до конца: 

Из какого вы лагеря? Из тех, кто считает, что нейросети нас погубят и заберут нашу работу, или тех, кто воодушевленно внедряет их в рабочие процессы, становясь при этом продуктивнее и энергичнее?

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

Привет, меня зовут Мария, я Senior UX-copywriter в компании Каруна. Мы — большая компания, поэтому найм людей у нас дело привычное, регулярное и поставленное на рельсы. Мы как-то с HR-департаментом обсуждали этот процесс, и я предположила, что некоторые соискатели могут использовать все прелести технологий для улучшения портфолио, усиления резюме или даже для выполнения тестовых заданий. Так родилась идея эксперимента: смогу ли я только с помощью нейросетей устроиться в Каруну разработчиком? А в UX/UI команду? А графическим дизайнером или SERM/SEO специалистом?

Исходя из 8 лет опыта коммерческой разработки, 3 лет тимлидства, 5 компаний за плечами, могу утверждать: многие соискатели в IT сфере часто после собеседований сидят в ступоре и переваривают события, в частности из-за того, что обескуражены поведением интервьюеров или их неожиданными и странными вопросами. Есть ощущение, что время от времени полезно переосмысливать стандарты проведения техинтервью. В этой статье поделюсь своими наблюдениями о собесах в индустрии веб-разработки: кто проводит, кто на них приходит, почему кто-то остаётся после них недоволен. Рассуждения будут касаться скорее мелких и средне-крупных компаний РФ и ближнего зарубежья, занимающихся веб-разработкой, чем гигантов отрасли, не говоря уже про FAANG.

Среди программистов не утихают споры о том, надо ли знать "алгосики" для реальной работы, или же это просто некий странный ритуал для прохождения воронки собеседований в компании а-ля FAANG (MANGA). У нас в Каруне в разных командах есть разные мнения на этот счёт. Я, например, как тимлид Go-команды считаю, что некую элементарную базу знать точно бы не помешало, но всё же главное, чтоб человек был хороший.

Мнения могут различаться, но одно я знаю точно: разгадывать загадки бывает очень интересно. Я как-то из любопытства прорешивал задачки на hackerrank, и, если для решения простых задач тупо достаточно догадаться отсортировать данные или построить map (даже не надо ничего особо знать), то для некоторых придумать решение довольно проблематично.

Одна из таких задач — нахождение самой длинной общей подпоследовательности (longest common subsequence). Подобный алгоритм используется в реальной жизни, в таких программах как diff. Скажу сразу: я не смог решить задачу самостоятельно за разумное время (т.е. пока не надоело решать) и посмотрел алгоритм в Википедии.

Но бог с ним с алгоритмом, мне стало жутко интересно, как же, блин, я должен был рассуждать, чтобы самому прийти к этому решению. В итоге эти рассуждения я решил выложить в виде статьи на Хабр.

Disclaimer: я точно не олимпиадник и не гуру алгоритмов, просто любопытствующий.