Программист
Привет, Хабр! Я Костя Макушев, работаю техническим писателем в подразделении ИТ-Инфраструктуры Т-Банка. В этой статье расскажу, какие проблемы возникли с пользовательской документацией наших продуктов и какие подходы мы начали применять, чтобы эти проблемы решить.
Статья будет полезна всем, кто занимается и интересуется документацией: техническим писателям, владельцам продуктов, менеджерам, тимлидам.
Привет, Хабр! Я Тимофей Милованов, ведущий Golang-разработчик в команде VoiceKit, где мы занимаемся голосовыми технологиями. Мы разрабатываем сервисы по распознаванию и синтезу голоса, преобразованию одного голоса в другой, а еще голосовой биометрией.
Расскажу о том, почему структура этих сервисов похожа на пайплайн, почему Golang отлично подходит для реализации пайплайнов и как мы написали свою библиотеку для этих пайплайнов.
Итак, мы с вами добрались до третьей, самой «хардовой» части цикла. Сегодня поговорим про gRPC.
Что такое gRPC?
Сам RPC — удалённый вызов процедур (иногда вызов удалённых процедур; RPC от англ. remote procedure call) — класс технологий, позволяющих программам вызывать функции или процедуры других программ, делая это так, как если бы они находились в одном адресном пространстве. Буква g в названии — это гугловая реализация этих технологий.
Разберем это все на примере.
Допустим, что вы — программист и сидите в монолитной репе. У вас одно приложение. Сам проект открыт в IDE и вы в нем работаете. В репе реализован определенный класс (например, на Kotlin), у которого есть метод, возвращающий вам данные по пользователю.
Привет! На связи Аркадий из Т-Банка, мы по прежнему делаем TQM, и в этой статье покажу, как мы решили задачу с поиском последовательностей в тексте коммуникаций. Это работает как на простых цепочках из словосочетаний по порядку, так и на сложных кейсах — со временем фразы, каналом «клиент — оператор». Мы по прежнему работаем с ElasticSearch, оставляя возможность “накрутить” на поиск по тексту такие вещи как RAG, LLM и другие модные технологии.
Несколько ограничений для сегодняшней задачи:
- Нелинейное возрастание сложности запроса при увеличении количества фраз. Поэтому предел у нас 4.
- Шаг тайминга мы выбрали 5 секунд. После каждой фразы ставим метку времени или несколько меток, если фраза заняла больше 5 секунд. Если сделать шаг слишком мелким это позволит искать более точно, но замусорит наше поле метками времени. Кажется, это тот момент когда лучше заранее договориться о требованиях.
А теперь к самому интересному. Добро пожаловать под кат!
Привет! Меня зовут Аркадий. Последние пару лет я в основном занимаюсь развитием поиска по тексту в команде TQM (Tinkoff Quality Management) в банке Тинькофф. Наш продукт — это речевая аналитика по звонкам, чатам и другим активностям, контроль качества, анализ и прочее. Более подробно о продукте можно прочитать на странице бизнес-решений. Примерный объем нашего индекса в проде — 16 Тб, около 450 млрд сущностей.
Каждый раз, когда встает вопрос о полнотекстовом поиске, команда оказывается перед выбором: а надо ли? Уже есть полнотекстовый поиск в Postgres, а тут придется заказывать серверы, строить кластер. Но чем чаще пользователю требуется что-то найти, тем чаще приходится смотреть в сторону специализированных поисковых движков.
Как пишут сами разработчики Elasticsearch, он нужен именно «для поиска, вы же знаете» (you know, for search) и не сможет заменить полноценное хранилище данных. Зато достаточно быстрый, очень надежный и хорошо горизонтально масштабируется (при наших объемах).
Мы в TQM используем Elastic потому, что он гибкий, широко известный, имеет удобный и простой синтаксис, множество библиотек для работы как на Python, так и на C# (NEST). Хорошо скейлится под наши объемы (1—30 Тб). Kibana также очень удобна, мы используем ее для мониторинга, консоль Kibana применяем для запросов. А еще по сравнению с тем же Sphinx, Elastic удобно масштабировать (просто добавляем шарды, ноды, и он сам распределяет данные по ним). В случае с тем же Sphinx нам пришлось бы писать этот распределенный поиск самим, и не факт, что у нас получилось бы хорошо с первого раза.
Привет, Хабр!
Меня зовут Рожнев Андрей, участник профессионального сообщества NTA.
Делюсь личным опытом по настройке терминала в Unix‑подобных ОС (macOS, Fedora, Ubuntu и так далее).
Когда я только залетал в отрасль софтверной разработки, первое, что меня напрягло — конечно же терминал и его неотвратимость. По итогу же оказалось, что терминал — это твой верный друг и соратник на тернистом, но таком интересном пути в мир IT. Один из вариантов полюбить терминал — потратить какое‑то время, немного разобраться в теме и настроить всё это дело под себя любимого.
В тексте написано кокой путь проходят сорцы с момента написания до исполнения на микроконтроллере. Также про то как настроить ToolChain из бесплатных утилит. Показано на что стоит обратить внимание при запуске первого проекта на Cortex-M чипах. Этот текст, в сущности, пояснение того, что происходит под капотом большинства IDE.
Часть 1
Часть 2
Часть 3
Часть 4
В завершающем посте этой серии мы рассмотрим Network namespaces. Как мы упоминали в вводном посте, network namespace изолирует ресурсы, связанные с сетью: процесс, работающий в отдельном network namespace, имеет собственные сетевые устройства, таблицы маршрутизации, правила фаервола и т.д. Мы можем непосредственно увидеть это на практике, рассмотрев наше текущее сетевое окружение.
Эта статья призвана познакомить читателя с находящимся в арсенале systemd набором инструментов.
Когда наконец удается смириться с уходом systemd от тех принципов, что лежали в основе ветхозаветной System V с ее простыми текстовыми файлами и засильем скриптов, начинаешь видеть неоспоримые преимущества новой системы инициализации и поставляемых с ней инструментов. В этой статье мы поговорим о четырех из них, а также упомянем еще один, который вы наверняка уже знаете, но вряд ли использовали описанным здесь способом.
Важная характеристика Docker-контейнеров — эфемерность. В любой момент контейнер может рестартовать: завершиться и вновь запуститься из образа. При этом все накопленные в нём данные будут потеряны. Но как в таком случае запускать в Docker приложения, которые должны сохранять информацию о своём состоянии? Для этого есть несколько инструментов.
В этой статье рассмотрим docker volumes, bind mount и tmpfs, дадим советы по их использованию, проведём небольшую практику.
1) начинающих реверсеров, знающих особенности обратного проектирования, и желающих изучить такой отладчик как GDB
2) как подсказка тем кто постоянно работает с IDA, Ghidra или любым другим мощным и надежным инструментом, но в силу тех или иных обстоятельств решить задачу проще и быстрее с помощью GDB, и не очень хочется залезать в официальную документацию и снова все вспоминать
В последнее время использование протокола HTTPS для Web-ресурсов является обязательным требованиям ко всем более-менее большим Web-проектам. Эта технология основана на использовании так называемых сертификатов. Раньше за получение своего сертификата нужно было платить. Но сегодня появление таких сервисов, как Let's Encrypt сделало возможным получение сертификатов бесплатно. Таким образом, цена больше не служит оправданием отказа от использования HTTPS.
В самом простом случае сертификат позволяет установить защищённое соединение между клиентом и сервером. Но это далеко не всё, на что они способны. В частности, недавно я смотрел на Pluralsight курс Microservices Security. И там среди прочих упоминалась такая вещь, как Mutual Transport Layer Security. Она позволяет не только клиенту убедиться в том, что он общается именно с тем сервером, с которым хочет, но и сервер может узнать, что за клиент с ним общается.
Всё это накладывает на разработчиков необходимость знать способы работы с сертификатами. Именно поэтому я и решил написать эту статью. Я задумал её как место, куда можно обратиться за основными сведениями, если что-то забудешь. Не думаю, что специалисты найдут в ней что-то новое, но надеюсь, что она будет полезна новичкам и тем, кто захочет освежить свои знания в этом вопросе.
За несколько недель до 14 февраля системе Dodo IS немного поплохело под нагрузкой. Одной из причин стало то, что в backend’ах мобильного приложения и сайта не совсем корректно работали политики поверх HttpClient’а (Retry, Circuit Breaker, Timeout). В этой статье я хочу поделиться с вами потенциальными проблемами, которые могут возникнуть при неправильном использовании таких политик.
