Команда Python for Devs подготовила перевод статьи о том, как с помощью LlamaIndex и Pydantic можно превратить сканы чеков в структурированные данные. Минимум кода — и у вас готовый CSV для анализа.
Когда мы начинаем работать с нагруженными системами, на передний план выходят задачи, как эту систему отмасштабировать — систем в стазисе не бывают. Они либо растут, либо умирают. Мы исходим из того, что системы растут по объёму задач, количеству запросов и другим критериям, по которым мы работаем с highload.
В «Сколково» в Москве 6-7 ноября пройдёт крупнейшая IT-конференция HighLoad++. Это самая высокая концентрация профессионалов из отрасли в стране: мероприятие направлено на обмен знаниями о технологиях, позволяющих одновременно обслуживать тысячи и миллионы пользователей.
В прошлом примере я рассказал о том, как можно использовать YDB в качестве векторной базы знаний. Сегодня расскажу про то, как использовать Yandex Embedder.
Но сначала несколько слов о том, почему Embedder — это очень важно.
Если ваш Битрикс тормозит, а Laravel кажется из другой вселенной — эта статья для вас.
На связи Алиса — тимлид в e-commerce агентстве KISLOROD. Мы ежедневно имеем дело с большими каталогами, сложной коммерцией и 1С, которая дышит в затылок. И однажды мы решили сделать невозможное: подружить Битрикс с Laravel. Так, чтобы Битрикс остался каноном и привычной админкой, а Laravel стал помощником — взял на себя API, тяжёлую бизнес-логику и все, что тормозит. Без форка ядра, слез SEO-шника и без утечек в 1С. Да, это реально.
Я прочитал статью, и меня поразило, сколько сомнительных решений можно использовать для одной простой задачи.
В этой статье я расскажу, как правильно создать сервис для конкурентных обновлений остатков данных в базе данных. Буду использовать .NET, C#, Entity Framework и PostgreSql.
Часть 3: А при чём здесь Thundering Herd?
В конце второй части я оставил вас с интригой: почему мой AI-ассистент решил поправить лектора и предложил термин Thundering Herd (несущееся стадо бизонов)?
У реляционных баз данных есть один небольшой недостаток - они не выводят табличные данные на экран пользователя. С одной стороны - какой же это недостаток, когда технология занимается исключительно своими базаданновыми вещами и не лезет туда, где её не надо. С другой - приходится данные пробрасывать через другой язык программирования, а то и два-три в случае веба. Ну и сам язык запросов забывать не надо. Он тоже вроде как язык.
Все существующие языки предназначены для уменьшения цифровой энтропии и оснащены инструментами для уборки цифрового навоза (кроме брейнфака, пожалуй). В том числе и инструментами для сбора в кучу разрозненных полей, да ещё и с возможностью как-то назвать эту структуру. В ООП языках это вообще часть парадигмы с далеко идущими последствиями, можно сказать, это у них в крови. А ООП языков, работающих между БД и экраном пользователя, осмелюсь предположить, большинство. Естественно, у разработчика возникает сразу желание воспользоваться структурными инструментами языка, чтобы утрамбовать поля таблицы в класс. Вот так и появляются дтошечки, энтитички, поджошечки и прочие попочки.
И вроде не велика проблема - делаем структуру в нашем любимом языке, такую же, как в БД и из наших кубиков складывается слово "счастье". Складываться-то оно складывается, но ненадолго. Очень быстро структура БД и структура в коде начинают разъезжаться. А если не начинают, то потыкайте в свой проект палочкой - скорее всего он уже умер. Как говорится "не щебечет дохлый щегол, а мёртвый проект не меняет свою структуру". Ну и далее по тексту...
Мониторинг состояния системы (процессов, запущенных служб и обмена данными по сети) играет очень важную роль при работе над сложной робототехнической системой. Наличие удобного инструмента для интроспекции состояния процессов упрощает работу разработчика позволяя быстро находить и исправлять неисправности и экономить время на ненужной отладке. В этой статье я расскажу о популярных инструментах мониторинга в ROS2. Кому интересно прошу под кат.
Когда я только начинал изучать Python, я впервые столкнулся с дескрипторами. Глядя на примеры с кодом, я никак не мог понять, зачем это вообще нужно, и как я могу использовать это для решения моих задач. В общем, при первом знакомстве дескрипторы показались мне странной вещью, без знания которой вполне можно обойтись. Несколько месяцев назад, я вернулся к теме дескрипторов и полностью изменил свое мнение. И вот почему.
Часть 2: В поисках классических проявлений Dogpile Effect.
Мое "расследование" началось с самого очевидного — поиска информации по термину Dogpile Effect. Хотелось найти каноническое определение термина Dogpile Effect.
Этим постом хочу открыть серию постов по материалам курса Архитектор ПО.
Управление репликами - как избежать проблемы Dogpile при горизонтальном масштабировании и что вообще такое Dogpile.
Организация рабочего пространства, будь что реального, что виртуального было всегда вопросом индивидуальным. Безусловно, порой есть best practictes: убрать всё лишнее с рабочего стола; отключить уведомления, иметь своё выделенное рабочее место. Вспоминаются сразу нон-фикшн литература о менеджменте пространства, психологии определённых ритуалов и атрибутов. Эта тема будто бы была актуальна всегда, и она настолько же исследована, насколько и индивидуальна: кто-то не может начать свой день, не погладив попугая на рабочем столе. Кто-то не может читать почту, пока не проведёт чайную церемонию, поливая телефон, мышку, колонку и прочее. Когда-то достаточно было просто стола и перфоратора, а сейчас сложно представить человека, работающего за компом без кресла - комбайна, которое затрагивает все частички твоей души в каждый конкретный момент; с механической клавиатурой, Дб нажатия клавиш которая должна быть всегда в пределах 55-60; диагональю монитора, чтобы он вмещал 2 любимые IDE, 1.5 любимых браузеров, 5 чатов с LLM, рабочий мессенджер (1 инстанст по каждой из работ). В каждой IDE 10 открытых pop-up’ов, 2 сплита на каждый буфер, 4 открытых таблиц, 7 активных докер exec bash процессов, 20 рабочих localhost вкладок и более 50 важных, но до сих пор не прочитанных; на каждое действие автокомплит + подсказка от агента + ai-powered copy/paste’ом c ai-powered буфером обмена с blazing fast и thread save обёрткой. Упс, не та тема уже; Общаясь с людьми, понимаешь, что всё чаще идёт сдвиг опциональных инструментов в первостепенные, и это то, о чем будет эта статья. Она не о хейте изобилия инструментария, она для рефлексии и инвентаризации того, что у вас уже есть.
Эта статья поможет вам создать приложение Express 5 с поддержкой TypeScript.
Вы настроите готовый к продакшну проект с помощью различных инструментов для линтинга, тестирования и проверки типов. В случае, если вы новичок в REST API, не волнуйтесь, эта статья также включает объяснения основных концепций, которые следует знать, таких как маршрутизация (роутинг) и аутентификация.
Настоятельно рекомендую писать код вместе со мной. Мы будем использовать подход "Разработка через тестирование" (test-driven development, TDD) для создания REST API, который может стать основой вашего следующего приложения Express.
Привет! Я Антон, инженер по информационной безопасности в Selectel. Под катом расскажу, как устроены автоматизированные системы, каким угрозам подвержены и какие меры действительно помогают защитить данные.
Статья о реализации параллельных SOAP запросов в PHP с использованием кастомного HTTP транспорта и Guzzle promises.
В предыдущей статье рассмотрены основы сборки RPM пакета и автоматизации процесса.
Данная публикация завершает цикл. Продемонстрировав практическую реализацию готового решения, включая:
Разработку Web сервиса.
Регистрацию сервиса в качестве системной службы с автозагрузкой (systemd) при установке пакета.
Внедрение централизованного логирования через journald.
В результате создана полнофункциональная заготовка для быстрого развертывания сервисов с последующей публикацией их в RPM пакет.
Привет Хабр! В этой статье я хотел поговорить о теме вечных конфликтов разработчиков на C++ и Rust. Стоит ли того система управления памятью в Rust или все-же это бестолковый механизм стремящийся составить конкуренцию родному методу?
Систему управления памятью я разберу, а вот выводы остаются уже за вами.
Привет, Хабр! Меня зовут Евгений, я — ведущий разработчик отдела SAP разработки.
Цель этой статьи — «подумать письмом» о том, что такое SAP UI5, каковы его особенности, преимущества и недостатки. Так же, рамках статьи попытаемся ответить на вопрос, стоит ли его использовать, а если стоит то, когда и зачем.
Точнее такой она была изначально. А на самом деле, преследуя исключительно личные корыстные интересы, я решил провести небольшое исследование, на обширную и трудно формулируемую тему «а не посмотреть ли мне в сторону web разработки на SAP UI5».
Основная целевая аудитория — это в первую очередь SAP ABAP разработчики и сочувствующие, которых интересуют похожие вопросы, а во вторую и последнюю — все остальные любопытствующие ИТ‑шники:)
Интересно? Читайте статью под катом.
Предупреждение: не сомневаюсь, что наверняка кто-то, прочитав данную статью, возжелает закидать меня тапками, но это его право, я не претендую на истину.
Я начал писать эту статью около двух месяцев назад. Писал по мере возможности и уже почти закончил, как буквально на днях было обсуждение именно этой темы с коллегами. По результатам услышанных там вопросов я добавил еще пару абзацев, чтобы постараться ответить на данные вопросы в комплексе. Эта статья лежала в черновиках с декабря 2021г, я совсем про нее забыл.
В наше время каждый слышал про Web-API и у многих это ассоциируется с REST. Однако этот многострадальный REST всегда какой-то не такой, с ним все время что-то не так.
Разработчики часто спорят и упрекают друг друга, что твой REST недостаточно REST-овый. Это стало чем-то вроде культа или даже религии. Я не планирую рассказывать о том, как правильно готовить REST, но весь материал именно вокруг этого многострадального RESTа.
Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.
GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы writeonly/readonly/compaction, один контейнер для старта и понятная философия «делай просто, делай быстро». Проект обещает суб-секундные аналитические запросы, компактизацию и дружбу с FDAP-миром (Arrow/DataFusion/Parquet/Flight) — всё то, что нравится инженерам, уставшим от «зоопарков» сервисов.