Пользователь
Сравнительный анализ Apache Kafka и RabbitMQ
В статье поговорим об особенностях, достоинствах и недостатках двух популярных брокеров сообщений. В каком случае использовать тот или иной брокер? Как с помощью брокеров достичь максимальную производительность и гибкость в обработке данных?
Тема будет интересна разработчикам на проектах, где требуется обмен информацией между разными компонентами или системами.
В стандарте SQL описывается четыре уровня изоляции транзакций — Read uncommited (Чтение незафиксированных данных), Read committed (Чтение зафиксированных данных), Repeatable read (Повторяемое чтение) и Serializable (Сериализуемость). В данной статье будет рассмотрен жизненный цикл четырёх параллельно выполняющихся транзакций с уровнями изоляции Read committed и Serializable.
Для уровня изоляции Read committed допустимы следующие особые условия чтения данных:
Неповторяемое чтение — транзакция повторно читает те же данные, что и раньше, и обнаруживает, что они были изменены другой транзакцией (которая завершилась после первого чтения).
Фантомное чтение — транзакция повторно выполняет запрос, возвращающий набор строк для некоторого условия, и обнаруживает, что набор строк, удовлетворяющих условию, изменился из-за транзакции, завершившейся за это время.
Что же касается Serializable, то данный уровень изоляции самый строгий, и не имеет феноменов чтения данных.
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
«Лама... Альпака...Чатгпт...» — раздавалась в уютненьком чатике по Ирине.
Хабр был не лучше — статьи по работе с GPT множились как грибы, а в комментах раздавались возгласы в духе «Дайте мне голосового помощника, с которым можно болтать!»
Если честно, еще в первой статье про Ирину я говорил, что небольшой фанат именно общения с виртуальным помощником. Помощник должен выполнять команды, казалось мне.
Тем не менее, и меня заинтересовало, насколько весело будет именно болтать с GPT, но самому в коде и платном API‑доступе разбираться не хотелось. Но сегодня утром меня снабдили и примером, и ключиком...
‑-
Это продолжение моих статей о разработке голосового помощника Ирины, не зависящего от крупных корпораций. У нас есть печеньки:
— Полностью оффлайн SpeechToText и TextToSpeech
— Поддержка плагинов
— Готовые команды «таймер», «погода» и ряд прочих. Поддержка HomeAssistant.
— Поддержка работы в клиент‑серверном режиме — сервер + куча микрофонов + Телеграм‑клиент, например.
Расскажу, что улучшилось за прошедший год с момента прошлой статьи.
TL;DR> Добавлен плагин для общения с GPT-3 нейросетью. Сделан пакет упрощенной установки под Windows — «скачай и запусти». Сделано два веб‑клиента — один распознает слова прям в браузере (тяжелый), другой отправляет весь звуковой поток на сервер (легкий) — так что можно запускать клиенты, например, на смартфоне. Добавлен TTS Silero v3 — имхо, лучшее озвучивание доступное в открытом доступе. Сделан докер‑образ для быстрого запуска Ирины без установки зависимостей. Добавлено нечеткое распознавание фраз. Обновлена VOSK‑модель распознавания голоса на специально натренированную для Ирины.
Данный туториал пошагово разбирает процесс создания веб-приложения для определения тональности текста на основе NLP-модели.
Мы будем использовать модель из библиотеки Hugging Face Hub, но описанный подход подойдет для любой задачи машинного обучения.
План:
1. Загрузка и подготовка модели машинного обучения для использования в веб-сервисе.
2. Создание веб-сервиса с помощью FastAPI.
3. Изучение пользовательского интерфейса FastAPI для удобного ручного тестирования и демонстрации работы приложения.
4. Написание автоматических тестов с помощью библиотеки pytest.
5. Запуск приложения в Docker-контейнере.
Код доступен на GitHub.
Если от работы уже тошнит, надо ли, стиснув зубы, мотивировать себя на новые свершения или это повод забить тревогу? Расскажу о том, как профессиональное выгорание однажды довело меня до депрессии, как своевременно его распознать и не дать ему разрушить вашу карьеру.
Год назад ФНС прекратила выкладывать базу ФИАС в формате DBF, теперь база доступна только в формате XML. Данные из DBF можно было вставлять в базу как есть, с XML так не получается, перед вставкой в базу, XML надо парсить, и это занимает время. Полная база ФИАС занимает 290 GB, парсинг такого объёма занимает значительное время.
Это время можно сократить, если парсинг распараллелить. Для этого надо разделить файлы на группы и каждую группу обрабатывать отдельно, но одновременно (процессоры давно многоядерные, надо не забывать этим пользоваться). Кроме того, конечно, надо использовать потоковый парсер, что бы не ждать полной загрузки файла в оперативную память.
Я разработал несколько скриптов для создания и импорта базы. Эта статья будет о том как с помощью этих скриптов развернуть базу ФИАС за 9 часов на 6-ти ядерном процессоре.
Unicode – это набор символов, целью которого является определение всех символов и глифов всех человеческих языков, живых и мертвых. Поскольку всё больше и больше программ должны поддерживать несколько языков или просто любой язык, юникод в последние годы приобретает всё большую популярность. Использование различных наборов символов для разных языков может быть слишком обременительным для программистов и пользователей.
К сожалению, юникод привносит свои требования и подводные камни, когда речь заходит о регулярных выражениях. Но в дополнение к сложностям, он также приносит и новые возможности.
Последние 4-5 десятилетий спрос на программистов вырос в сотни раз. По некоторым оценкам их количество удваивается каждые пять лет, и в результате программист с 5-летним опытом работы имеет стаж работы в отрасли больший, чем у половины всех ее сотрудников.
Эрик Дитрих* около 10 лет провел на должностях, где его основной функцией было написание кода. Еще 10 лет были связаны с управлением программистами, их обучением, консультированием организаций, практикой оценки кодовой базы, а в наши дни и контент-маркетингом. Но во всех этих ролях он в той или иной степени писал код. И, по своим расчетам, прошел больший путь, чем 94% работающих в отрасли. Получается некое противопоставление: программист со стажем, который общается с кучей новичков в программировании.
Специально для своего блога Эрик попытался обобщить весь свой опыт в виде кратких советов, которые он хотел бы дать молодым программистам. Под катом — наиболее важные, на взгляд автора, уроки и выводы из его 20-летней карьеры.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Давайте обсудим как выглядят фреймы на каждом этапе передачи от клиента к коммутатору, к роутеру, к межсетевому экрану и к серверу и какие поля при этом там меняются.
Сегодня Docker является одним из самых популярных инструментов в области контейнеризации. В основе Docker заложена концепция использования контейнеров. С технической точки зрения контейнер — это процесс, наподобие тех, которые запускаются в операционных системах. Как и любой другой продукт, Docker подвержен различным атакам и уязвимостям.
В этой статье будут рассмотрены методы, которые помогут повысить уровень безопасности контейнеров Docker.
Низкий порог входа и строгость языка программирования — вещи обычно несовместимые. Потому что ты либо, как Rust, бьёшь по рукам borrow checker’ом — либо, как PHP, позволяешь не задумываться о типах и быстро прототипировать.
На самом деле, если писать код грамотно, это становится неважным и язык перестаёт иметь значение. Архитектура важнее языка, и хороший код на PHP ничем не отличается от аналогичного кода на любом другом ООП-языке. Другое дело, что возможность «любой домохозяйке» писать на PHP сопровождается и риском наворотить полное неподдерживаемое безобразие. Поэтому нам нужны тайпхинты, линтеры, статические анализаторы и подобные инструменты.
Но в PHP есть и ещё один изъян: в нём любой класс, функция или константа — глобальны. Можно создать класс из любого места в коде, и нет способа скрыть его или сделать деталью реализации где-то в отдельной папке. Иными словами, в PHP нет того, что в других языках называется модулями.
Наша новая open-source разработка называется Modulite и внедряет в PHP модули. Это сквозная технология: мы внедряемся в IDE, в PHPStan, в KPHP, в CI, в Composer — и делаем так, будто бы модули нативно есть в языке PHP.
Данный текст — продолжение серии статей, в которых я рассматриваю структуру (предположительно) готовящейся к выходу в этом году распределенной сети Telegram Open Network (TON). В предыдущей части я описал её самый базовый уровень — способ взаимодействия узлов между собой.
На всякий случай напомню, что к разработке этой сети я отношения не имею и весь материал почёрпнут из открытого (хотя и непроверенного) источника — документа (ещё к нему есть прилагающаяся брошюра, излагающая вкратце основные моменты), появившегося в конце прошлого года. Объем информации в этом документе, на мой взгляд, свидетельствует о его подлинности, хотя никаких официальных подтверждений тому нет.
Сегодня посмотрим на основной компонент TON — блокчейн.
Статья написана по мотивам моего доклада на митапе. В нем я рассказываю историю того, как мы взяли и не распилили монолит на микросервисы, и что сделали вместо этого.
На тот момент наша команда работала над приложением, начало которому было положено еще в 2009 году не искушенными в архитектуре студентами. К 2018 это уже был типичный big ball of mud (большой ком грязи), или, этакий «монолит-копролит», как выразился один наш коллега. Думаю, многим знакомо.
Всем привет, меня зовут Авксентий, я backend-разработчик в inDriver. Думаю, каждый начинающий разработчик сталкивался с проблемой, как правильно выстроить архитектуру и структуру проекта. Ведь организация кода проекта — постоянно развивающаяся проблема, а следование стандартной структуре сохраняет чистоту кода и повышает производительность команды.
Когда я начинал писать на Go, то потратил много времени на поиски стандартов структурирования проекта. В итоге так и не нашел официального и точного стандарта — либо информация была неполной, либо это было не то, что нужно. Я решил написать свой гайд на основе опыта. Он для начинающих разработчиков и посвящен тому, как структурировать проект на Golang.
Привет! А вот и вторая часть поста про принципы юнит-тестирования. Если в первой мы обсудили влияние тестов на разрабатываемые продукты и познакомились с теорией юнит-тестирования, то в этой обсудим некоторые практические моменты. Внутри поста — структура юнит-тестов, стили юнит-тестов, принципы рефакторинга, полезные советы для того, чтобы ваши юнит-тесты были эффективными и читаемыми, а также некоторые антипаттерны при написании тестов.
Ну и, конечно же, список источников, где можно получить дополнительную полезную информацию. В общем, начнём.
Структура юнит-тестов
В нашей команде при написании юнит-тестов мы стараемся использовать подход AAA — Arrange, Act, Assert (Подготовка, Действие, Проверка).
Кратко расскажу о нем. Тест делится на три блока, которые идут друг за другом. Ширина блоков на рисунке выше образно отражает объём кода, который должен занимать каждый из блоков.
У меня есть две статьи-интервью вот с такими странными абзацами. За обоими кроются неприятные истории для меня и для людей, про которых я писал.
Микросервисы сейчас — это новый черный. Все больше и больше компаний переходят именно на микросервисную архитектуру. И при переходе ловят самые разные ошибки. Самая популярная происходит из-за того, что люди просто не готовы к тому, что их приложения начинают активно использовать сеть. Потому что IPC и RPC-запросы — это абсолютно разные вещи.
Я техлид в команде Авито в проекте SLA. Сегодня расскажу, как мы оптимизировали сетевые вызовы, чтобы избежать проблем с сетью при переходе в микросервисный мир. Разговор будет про оптимизацию CURL-запросов, деградацию сервисов и FAIL-FAST-подходы.
Привет, меня зовут Петр и я работаю в Badoo в команде биллинга. В этой статье я хочу поделиться своим опытом работы над пет-проектом по созданию хранилища фотографий с возможностью поиска дубликатов. Я расскажу, с каким багажом я вошел в этот проект, в чем заключалась задача и как её решал. В конце поделюсь результатами и почему я считаю, что это один из лучших проектов, которым я занимался.
Однажды мои знакомые попросили сделать им хранилище изображений для их проекта по модерации внешних ресурсов. Условия: срок хранения до трех лет, фотографии при этом присылаются неравномерно, в среднем поток — 150.000 картинок в сутки.
Казалось бы, достаточно банальная задача. Если бы не еще одно условие: хорошо бы сопоставлять фотографии с уже имеющимися: искать дубликаты и помечать их.
Помогая пользователям NGINX с разрешением проблемных ситуаций, мы поняли, что большинство из них часто совершает одни и те же ошибки конфигурации. Более того, подобные ситуации вполне могут возникнуть даже у самих инженеров NGINX! В этой статье рассмотрим 10 наиболее распространенных ошибок и объясним как их исправить.