Разработчики всё чаще полагаются на ИИ-помощников, чтобы ускорить повседневную работу с кодом. Эти инструменты умеют автозаполнять функции, предлагать исправления ошибок и даже генерировать целые модули или MVP. Тем не менее, как многие из нас убедились, качество вывода ИИ во многом зависит от качества предоставленного запроса. Плохо сформулированный промпт может привести к нерелевантным или общим ответам, в то время как хорошо составленный — дать продуманные, точные и даже креативные решения для кода.

Под катом Эдди Османи, ведущий инженер Google, выделяет ключевые шаблоны запросов, повторяемые фреймворки и запоминающиеся примеры, которые нашли отклик у разработчиков.

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

Если в компании налажен контроль доступа к внутренним ИТ-ресурсам, хорошо не только спецам по ИБ, но и многим другим. Например, лидам, которые отвечают за доступы к базам данных в своих командах. И новым сотрудникам, избавленным от необходимости вручную собирать логины-пароли, а затем где-то их самостоятельно хранить. 

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

Под обе эти задачи заточены так называемые PAM-инструменты (Privileged Access Management). Под катом рассказываем, как мы обеспечили контроль доступов и аудит инфраструктуры с помощью одного из них. В том числе об особенностях его внедрения, возможностях и некоторых ограничениях, выявленных на практике. 

Опыт пользователя — понятие составное. В случае с ИТ-продуктами это и про логику интерфейсов, и про типографику, и про специфику дизайн-системы; наконец, в целом про то, как клиент воспринимает продукт, начиная с этапа его поиска/приобретения.

На уровне отдельных аспектов оценивать UX, UI и CX нам помогают те или иные виды исследований. Но когда речь идёт о разноплановых продуктах с различными пользовательскими сценариями, задумываешься об унификации. Возникает вопрос: можем ли мы оценивать опыт пользователя комплексно — по единым критериям и в рамках одной методологии?

В Сравни для решения этой задачи мы разработали и внедрили Product Score — скоринговую модель оценки UX, UI и CX. С её помощью получаем независимую оценку продуктов, формируем конкретные гипотезы по развитию пользовательского опыта и пополняем бэклог улучшений.  

Под катом рассказываем, как устроен наш Product Score. И подробно раскрываем методологию оценки на практических примерах.

Цикл продуктовой разработки часто напоминает весы: с одной стороны, системное проектирование, подбор основополагающих инструментов, масштабные рефакторинги. С другой — совокупность локальных решений, принимаемых для точечных улучшений в системе. И самое сложное тут: соблюдать баланс. Как понять, когда имеет смысл вмешаться «хирургически», а когда — предпочесть вместо конкретной проблемы решить (или предотвратить) целый класс проблем?  

Иногда нащупать границу между «масштабом» и «целесообразностью» получается почти что случайно. Однажды мы в Сравни подступились к переделке чата в нашем мобильном приложении, и на старте расценивали задачу как «ещё один рядовой продуктовый кейс». Но планы по модификации фичи быстро переросли в создание универсального инструмента: конструктора сценариев на базе Backend Driven UI.

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

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

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

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

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

Для команды резкое масштабирование процессов — всегда стресс, а если речь идёт о поддержке, то бывает совсем тревожно: работа саппортов и без того зачастую проходит в напряжённом темпе. Так что же делать, когда бизнес растёт, а вместе с ним — количество и разнообразие обращений, включая весьма нестандартные вопросы? Кажется, решение в духе «нанять побольше саппортов» здесь не всегда может быть оптимальным.

Задачу «выстоять под шквалом тикетов» мы в Сравни условно декомпозировали на три составляющие. Оптимизировали ту механику общения с клиентами, которая у нас уже имеется; проработали новую программу онбординга; внедрили технический инструмент, чтобы упростить саму работу с тикетами. Это помогло не только выровнять процессы под растущий бизнес, но и заблаговременно подготовиться к будущему росту обращений.

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

Этот пост — погружение в кроличью нору. Разработчик Монсеф Аббад задумался о изображениях — вероятно, после недавнего изучения им некоторых схем компрессии. Общеизвестно, что изображения бывают либо полутоновыми, либо RGB, когда новые цвета создаются на основе смешения красного, зелёного и синего. Но для хранения изображения требуется нечто большее, чем просто выравнивание трехбайтовых значений RGB.

Что-то в этой идее пробудило любопытство автора, поэтому в статье он попытался удовлетворить его и ответить на вопрос: как на самом деле хранятся изображения?

Где именно юристы пересекаются с ИТ?

Ответ здесь может быть долгим. Тимлиды регулярно принимают решения о выборе технологий и инструментов, менеджеры управляют ИТ-проектами с учетом сроков и бюджета, а разработчики пилят полезные сервисы и фичи. Каждый из них сталкивается с правовыми аспектами своей работы: от проверки лицензий open source компонентов до простого (иногда в кавычках) оформления договора с подрядчиком.  

Часто коммуникация юристов и ИТ-спецов напоминает диалог двух разных миров: технический жаргон встречается с правовыми терминами; планы по запуску прорывных решений — с рядом законодательных ограничений.

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

Оба этих аспекта раскрываем под катом, в формате памятки. 

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

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

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

В Android-разработке могут возникать сценарии, когда нам нужно собрать один aar из нескольких модулей. 

Однажды нам в Сравни потребовалось создать SDK для наших партнёров — на основе уже существующего проекта. Сделать это хотелось без радикальных изменений в проекте и излишнего раскрытия деталей его устройства.

Задача понятная, но нетривиальная в реализации. Google до сих пор не предоставляет полноценного инструмента для создания fat-aar; к opensource-решениям также много вопросов. 

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

О том, как мы к этому подступились и к чему пришли, рассказываем под катом.

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

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

Эрик Закариассон, разработчик и автор блога Anyblockers, рассмотрел в своей статье, как использовать Postgres для создания надёжной поисковой системы. В рамках задачи автор объединил три техники:

1. Полнотекстовый поиск с tsvector

2. Семантический поиск с pgvector

3. Нечёткое сопоставление с pg_trgm

4. Бонус: BM25

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

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

Под катом рассказываем о том, по каким принципам работает наша платформа, какую роль в её устройстве играет Saga MassTransit и как посредством решения происходят интеграции с банками. Плюс раскрываем процесс самой интеграции — на конкретном кейсе.

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

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

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

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами. 

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

Ответить на подобные вопросы помогает решение задач в духе «сегментация чего-либо по имеющимся данным».

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

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

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

Эра Unix — это дата, которая жёстко закодирована в компьютерах повсеместно. Возможно, это самая известная дата в вычислительной технике, и она будет существовать до тех пор, пока у нас есть системы, основанные на Unix.

Эра определяется как начало определённого отрезка в истории чего-либо. К сожалению, эпоха Unix по факту — просто произвольная дата. Конечно, она близка к дате начала разработки Unix, но, как позже стало известно, выбрана она была не поэтому.

Хотя исторически эра Unix — дата произвольная, так получилось, что она совпала со знаменательной датой для компьютерной индустрии. Это невероятное совпадение, учитывая, какое значение эта дата имела для индустрии ПО. Она особенно важна для инженеров-программистов, потому что именно в этот день,1 января 1970, ИТ-рынок и индустрия в их современном виде были узаконены.

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

В Сравни у нас много продуктов, включая сервисы подбора и покупки полиса ОСАГО, подбора кредита, образовательных курсов, онлайн-оформления ипотеки. Информация о пользователях хранится и обрабатывается в специальном центральном сервисе (Profile Service). На текущий момент сервис содержит миллионы объектов пользователей, а нагрузка в пиковые моменты там до 180 запросов в секунду.

Исходная реализация Profile Service была построена на микросервисах и, как казалось нам ранее, полностью покрывала наши потребности: в плане гибкости взаимодействия с продуктами и работы с существующей нагрузкой. Изменения назрели под конец прошлого года, когда продуктовые команды стали настойчиво обращаться в команду сервиса для решения срочных задач. Здесь им регулярно требовалась помощь разработчиков — и команда Profile Service около месяца занималась только обработкой продуктовых запросов.

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

Стремительное развитие искусственного интеллекта привело к бурному росту числа вакансий в этой области, и сегодня многие люди строят в ней увлекательную карьеру. На протяжении многих лет американский учёный Эндрю Ын наблюдал, как это происходит у тысяч студентов, а также инженеров в больших и малых компаниях. Теперь он предлагает практическую схему, по которой можно проложить собственный карьерный трек. 

О трех ключевых составляющих этой схемы — обучении базовым навыкам, работе над проектами и поиске работы, — читайте под катом. 

Нужно ли тестировщику разбираться в базах данных? Короткий ответ: да, как минимум на том уровне, чтобы можно было успешно выявлять и локализовывать ошибки в их работе. На практике же проблемы в базах данных зачастую фрустрируют даже опытных QA-инженеров. Что-то где-то пошло не так, но что именно и где?

Разумеется, БД — вовсе не черный ящик с магией внутри, а такой же набор взаимодействующих по определенным правилам компонентов, как и все остальное, с чем ежедневно приходится иметь дело QA-инженерам (и разработчикам, на самом деле, тоже, но они обычно больше погружены в контекст). Понимание того, что там под капотом, помогает эффективно проводить тест-дизайн, локализовывать баги, общаться с разработкой.

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

Автоматизация — краеугольный камень современной аналитики, и речь здесь не только о том, чтобы оптимально настроить масштабные базовые процессы вроде CI/CD. Точечное внедрение инструментов и фреймворков, исходя из конкретной задачи, могут дать ощутимый быстрый эффект как минимум на уровне экономии времени. И стать предпосылками к более крупным оптимизациям.

Одним из наших локальных кейсов автоматизации в Сравни делимся под катом. Рассказываем, как наладили регулярный процесс сверки данных из десятков таблиц силами одного специалиста, с помощью уже имеющихся в компании инструментов — low code-платформы и мессенджера.

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

Линус Торвальдс как-то написал в своей книге, что создавал Linux для развлечения, но в итоге это привело к революции. Git, его второе творение, также оказалось «случайной революцией» — и сегодня это стандартный инструмент для людей в ИТ. Однако процесс его создания был уже не таким «весёлым» — по крайней мере, для самого Линуса.