Делимся в комментах ссылками на свои проекты, получаем обратную связь, знакомимся и исследуем чужие продукты!

Хранение денежных сумм в базах данных и API: анализ подходов платежных систем

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

Разбираем, как решают эти проблемы Stripe, PayPal, Google Wallet и другие платежные системы. Сравниваем три основных подхода: Integer minor units, Decimal base units и String base units.

Привет, Хабр!

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

Давайте честно: менеджер по большей части работает ртом. Договаривается, придумывает решения, продаёт эти решения окружающим, обосновывает, пинает, пинает, эскалирует, просит… Короче, говорить и объяснять ему приходится примерно все время. И умение четко и ясно доносить свои мысли в правильном ключе для менеджера – критично.

Как говорить так, чтобы от вас не отворачивались через 2 минуты с зевком? Как быстро объяснять занятым людям, в чем смысл вашего вопроса и чего вы хотите? Как сделать так, чтобы ваши вопросы решались руководителями за 2 минуты, вместо недель ожидания аудиенции? Ну и вообще: как перестать быть душным и негативным и стать быстрым и позитивным всего за пару приемов (не таких уж и простых, но все же)?

Вот об этом коротенько давайте поговорим в этой статье.

Эта статья написана по мотивам публикаций в моем ТГ канале «Морковка спереди, морковка сзади», который полностью посвящен управлению в IT, особенно в том, чему никто толком не учит – сфотскиллам. Если вам это интересно, заходите, читайте и подписывайтесь. Ну и читайте другие мои статьи на Хабре про управление.

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

1. Самое простое, что позволит улучшить работы с Cursor — это использовать Cursor Rules

Что это даёт?

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

Документация здесь.
А тут отличные заготовки для правил

2. Включайте сразу несколько ИИ-агентов

В Cursor можно открыть 3 вкладки, где параллельно будут работать 3 ИИ-агента (это максимум). Единственное что - контролируйте, чтобы они они не использовали дни и те же файлы — могут перезаписать или удалить результаты работы другого агента, так что им нужно давать изолированные задачи.

Дополнительно можно ещё использовать фонового агента, который работает на серверах Cursor, и будет выполнять задание на основании вашего кода в репозитории. А потом все его результаты можно отправить в репозиторий или локально, однако он работает за дополнительную плату (Price-based)

Можно даже открыть второй Cursor, и запустить работу ещё там (особенно если работа ведётся с кардинально разными репозиториями), но это не очень удобно с точки зрения переключения между ними.

3. Кладите связанные репозитории в 1 папку и открывайте её в Cursor

Допустим, у вас есть бэкенд, фронтенд и ещё микросервис для управления подписками. Если вы поместите их в 1 папку и откроете её в Cursor, то он сможет ходить между ними и делать согласованный код. Допустим, он может сразу сделать контроллеры на бэкенде и api для них на фронтенде.

Сколько времени нужно, чтобы завязать шнурки? Ну, секунд десять. А чтобы написать инструкцию, как завязывать шнурки?

Вот и в софте у нас самая честная оценка - я не знаю.

А как быть, когда все же надо дать оценку? Чтобы ответить на этот вопрос, подготовил небольшой обзор, в котором мы рассмотрим:

1. Что твердят источники

2. Что творит индустрия

3. Что говорит здравый смысл

Я начал использовать Nginx более 20 лет назад, и как-то привык к тому что это решение по умолчанию при выборе веб сервера. В своем пути в IT я начинал с linux администрирования, потом был мелкий онлайн бизнес, работал бизнес аналитиком, продактом, временами что-то программировал для себя. Обстоятельства опять поменялись и год назад я устроился работать девопсом в маркетплейс доменов, по сути такой возврат к истокам. Первая задача которую мне выдали - перевести паркинг с 100к доменами с nginx на caddy. На тот момент я не слышал про Caddy, но был очень хорошего мнения о nginx. 

Я был удивлен, зачем?!
Что такого может быть в каком-то другом веб сервере, чего не умеет nginx? 

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

В этой статье я изложу кейс, нюансы, которые становятся важными когда у вас 100к клиентских доменов, на которых должен работать https. И какие тут есть преимущества у Caddy перед Nginx. На хабре есть всего несколько статей по Caddy, и это незаслужено мало для него. Поэтому я надеюсь из этого кейса вы сможете узнать что-то интересное.

Возникла необходимость зафиксировать опыт с последнего проекта по прокачке производительности картографического сервиса. Так сказать, чтобы 2 раза не вставать при передаче опыта. И начнём с постановки, чтобы сразу определиться с аудиторией, кому мимо, а кому больше узнать как "прожевывать" и отображать на UI от 100К объектов в секунду и не лагать. Ну а кто-то вообще не в танке про картографические сервисы и хочет "на борт".

Что вас ждёт по катом.

1. MapTiler/Maplibre - картографический провайдер и UI фрэймворк для работы с ним.

2. Создание своих слоёв данных на карте.

3. Рендеринг большого объёма данных на WebGL/WebGPU. Начнём от 100К.

4. Оптимизация рендеринга с ручной подготовкой буферов для GPU.

5. Обновление данных слоя в realtime. Начнём молотить от 1M объектов.

6. Сериализация данных в ArrayBuffer для передачи напрямую в GPU.

Немного предыстории, прежде чем начать — о том, что у меня за проект такой — Talkvio. Уже два года я в свободное от основной работы время разрабатываю свой пет-проект — Talkvio, альтернативу Пикабу, где всё должно быть лампово и плюшево.

Проект уже довольно сильно развился: там есть нейросети для проверки орфографии, автотегов и помощи в формировании контента и заголовков. Есть Android-клиент, а iOS-версия находится в разработке. Реализована похожая система кармы, как на Хабре, есть даже минусы (привет администрации Пикабу), и многое-многое другое.

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

Забегая вперед, чтобы читателю было интересно, ресурс НЕ использовал Cloudflare.

В последнее появилось много компактных NAS с основным хранилищем на SSD носителях и с десяти гигабитным Ethernet. Высокая скорость работы твердотельных дисков в связке с высокой скоростью обмена по сети, прекрасно раскрывают возможности новой техники, а самое главное оправдывают ожидания их владельцев от новых технологий.

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

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

IP сообщает, откуда пришёл запрос, и на этом всё. Он не сообщает, какой язык нужен пользователю, на каком языке он говорит и какой язык понимает. Подобная система постоянно ломается — VPN, путешествия, эмиграция, страны с несколькими официальными языками. Это не умное, а раздражающее решение.

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

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

Да, это возможно!

Под катом описание архитектуры поискового движка Summa на Rust и набора приемов, позволивших ответить утвердительно на все вопрос

Приложения тормозят. Пользователи уходят. Бизнес недоволен. Знакомая картина? Часто корень зла – медленный доступ к данным. Кеширование может стать спасательным кругом. Но это не серебряная пуля. Неправильно настроенный кеш – источник новых проблем, иногда похуже старых.

Меня зовут Дмитрий Успенский, я работаю в команде ML RnD Техплатформы Городских сервисов Яндекса, и в статье я расскажу, как мы применили подход LLM as a judge — когда сама языковая модель оценивает качество генераций и сравнивает между собой разные варианты описаний. Поделюсь опытом определения критериев качества, сбора валидационного датасета, подбора промптов и выбора модели. Результаты оказались обнадёживающими: метод действительно позволяет улучшить генеративную систему без участия ручной разметки и асессоров.

Киберспорт - одна из любимых корпоративных активностей в ЛАНИТ. У нас есть крутое сообщество, участники которого постоянно выступают на соревнованиях и нередко становятся их победителями и призерами. Для успешных состязаний на турнирах игроки уделяют большое внимание своим «кибердоспехам»: гейминговым сетапам и периферии. В этой статье наши коллеги рассказали, как они обустроили свое игровое место и что, кроме технических средств, помогает побеждать, выдерживая многочасовые сражения.

Краткое примечание о значении "вайб-кодинга" (vibe coding): В этом посте я исхожу из того, что вайб-кодинг повзрослеет, и люди будут использовать его для настоящей инженерии, а версия "отключи мозг" останется только для прототипирования и забавных проектов. Для меня вайб-кодинг просто означает позволить ИИ делать работу. Насколько внимательно вы решите следить за работой ИИ, зависит исключительно от решаемой задачи. Для продакшена вы внимательны; для прототипов вы расслабляетесь. В любом случае, это вайб-кодинг, если вы не написали это вручную.

Еще одно примечание: Месть происходит в самом конце, как в кино.

ОК! Разобравшись с этими административными вопросами, поехали!

Всем привет! Меня зовут Диана Бутько, я студентка 3 курса, изучаю информационные системы и программирование. В InfoWatch я пришла на практику, и одной из моих задач стал сравнительный анализ различных методов поиска похожих векторов. Это один из ключевых аспектов машинного обучения и анализа данных, используемых в рекомендательных системах, кластеризации, семантическом поиске и других областях. Но чем больше объем данных, тем важнее становится выбор инструментов: полный перебор векторов требует больших вычислительных ресурсов, а в других алгоритмах порой необходимо балансировать между точностью и скоростью поиска.

В этой статье я сравниваю пять методов поиска похожих векторов:
— полный перебор по евклидову расстоянию с реализацией в Python;
— FAISS с индексами IndexFlatL2 (полный перебор, евклидово расстояние) и IndexIVFFlat (сегментирование по ячейкам, евклидово расстояние);
— векторный поиск в ClickHouse с индексом HNSW и метриками расстояния L2Distance (евклидово расстояние) и cosineDistance (косинусное сходство).

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

Единственное, о чем мы пожалели — что не применили это решение раньше.