Привет! После долгой паузы мы наконец-то возвращаемся к разбору Apache Flume. В предыдущих статьях мы познакомились с Flume (Часть 1) и разобрались, как настраивать основные его компоненты (Часть 2). В этой, заключительной, части цикла мы рассмотрим следующие вопросы:
Привет! В этой статье я хочу рассказать о системе антиспама в Почте Mail.Ru и опыте работы с Tarantool в рамках этого проекта: в каких задачах мы используем эту СУБД, с какими трудностями и особенностями ее интеграции столкнулись, на какие грабли наступали, как набивали шишки и в итоге познали дзен.
Читать полностью »
— А не западло ли вам там в банке отвечать на анонимные вопросы?
— Нет, Владимир Петрович, не западло.
Один из крупнейших коммерческих банков Беларуси Приорбанк, входящий в австрийскую группу «Райффайзен», использует голосовые эталоны (или, как ещё говорят, голосовые «отпечатки») клиентов для подтверждения их личности при обращении по телефону. Это пока только второй случай на территории России и СНГ, когда банк официально заявил о факте использования такой технологии.
Про саму голосовую биометрию мы уже рассказывали (возможность «узнавания» и определения личности звонящего, например в контакт-центр абонента, даже если он использует другой телефон или представляется кем-то другим — это актуально для антифрода). Расскажу о том, какие особенности есть во внедрении голосовой биометрии на примере Приорбанка.Читать полностью »
Одна из основных функций десктопного клиента Облака Mail.Ru — синхронизация данных. Ее целью является приведение папки на ПК и ее представления в Облаке к одинаковому состоянию. При разработке этого механизма мы встретились с некоторыми, с первого взгляда, достаточно очевидными особенностями различных файловых и операционных систем. Однако если о них не знать, можно столкнуться с довольно неприятными последствиями (не получится загрузить или удалить файл). В этой статье мы собрали особенности, знание которых позволит вам правильно работать с данными на дисках и, возможно, убережет от необходимости срочного хотфикса.
Читать полностью »
Многие знают про отличную библиотеку Automapper. С преобразованием Entity -> Dto проблем обычно не возникает. Но как обрабатывать обратный маппинг в случае, когда в API приходит корень агрегации? Хорошо, если read и write — контексты разделены и писать можно из Dto. Чаще, однако, нужно выбрать соответствующие сущности из ORM по Id и сохранить агрегат целиком. Занятие это муторное, однако зачастую поддающееся автоматизации.
Читать полностью »
В первой части мы показали как создать алгоритм работы на основе «конечных автоматов» в SimInTech и использовать его совместно с «классическими» алгоритмами в виде функционально блочных диаграмм.
Во второй части мы покажем как создать вложенные и параллельно работающие конечные автоматы и осуществлять обмен данными между ними.
Читать полностью »
В очередной раз хочу предложить свой перевод статьи, на этот раз автор Тодд Хофф, и его статья посвященна архитектуре WhatsApp на момент его покупки Facebook.
Ремарка: в начале статьи содержится рассуждение автора оригинала о том, зачем Facebook купил WhatsApp за баснословные 19 миллиардов. Если это вам не интересно — просто пролистайте, описание архитектуры будет ниже.
Рик Рид в его предстоящем мартовском докладе, озаглавленном "Миллиард с большой 'М': Следующий уровень масштабирования в WhatsApp" раскрывает сногсшибательную статистику WhatsApp:
Что имеет сотни узлов, тысячи ядер, сотни терабайт RAM и надеется обслужить миллиарды смартфонов, которые вскоре станут реальностью по всему миру? Основанная на Erlang и FreeBSD архитектура WhatsApp. Мы столкнулись со многими трудностями при удовлетворении постоянно растущего спроса на наш сервис обмена сообщениями, но мы продолжаем расширять нашу систему с точки зрения размера (> 8000 ядер) и с точки зрения скорости (>70М сообщений Erlang в секунду).
Kaggle — это платформа для проведения конкурсов по машинному обучению. На Хабре частенько пишут про неё: 1, 2, 3, 4, и.т.д.
Конкурсы на Kaggle интересные и практичные. Первые места обычно сопровождаются неплохими призовыми (топовые конкурсы — более 100к долларов). В последнее время на Kaggle предлагали распознавать:
И многое-многое другое.
Мне давно хотелось попробовать, но что-то всё время мешало. Я разрабатывал много систем, связанных с обработкой изображений: тематика близка. Навыки более лежат в практической части и классических Computer Vision (CV) алгоритмах, чем в современных Machine Learning техниках, так что было интересно оценить свои знания на мировом уровне плюс подтянуть понимание свёрточных сетей.
И вот внезапно всё сложилось. Выпало пару недель не очень напряжённого графика. На kaggle проходил интересный конкурс по близкой тематике.Я обновил себе комп. А самое главное — подбил vasyutka и Nikkolo на то, чтобы составить компанию.
Сразу скажу, что феерических результатов мы не достигли. Но 18 место из 1.5 тысяч участников я считаю неплохим. А учитывая, что это наш первый опыт участия в kaggle, что из 3х месяц конкурса мы участвовали лишь 2.5 недели, что все результаты получены на одной единственной видеокарте — мне кажется, что мы хорошо выступили.
О чём будет эта статья? Во-первых, про саму задачу и наш метод её решения. Во-вторых, про процесс решения CV задач. Я писал достаточно много статей на хабре о машинном зрении(1,2,3), но писанину и теорию всегда лучше подкреплять примером. А писать статьи по какой-то коммерческой задаче по очевидным причинам нельзя. Теперь наконец расскажу про процесс. Тем более что тут он самый обычный, хорошо иллюстрирующий как задачи решаются. В-третьих, статья про то, что идёт после решения идеализированной задаче в вакууме: что будет когда задача столкнётся с реальностью.
Читать полностью »
Эти и другие вопросы я часто слышу от технических писателей на конференциях. Для небольших объёмов документации достаточно вручную пересмотреть документы и обновить/подставить/поправить всё, что нужно. А если объёмы документации выросли?
Наша документация выросла до более чем 154 000 документов только по .NET-линейке продуктов, из них около 140 000 документов — это справка по API. Около 8-10 тысяч топиков добавляются каждый мажорный релиз (т.е. дважды в год). В этой статье я расскажу как мы справляемся с такими объёмами.
Здесь я не приведу названия общедоступных инструментов, потому что всё, что мы используем — это самописные приложения и сервисы, которые глубоко интегрированы в нашу инфраструктуру и слабо применимы вне её. Поэтому в этом хабратопике я поделюсь техническими решениями, а не инструментами.
В наши дни NoSQL продолжает набирать популярность, но мало кто знает, что нереляционные СУБД появились гораздо раньше даже самой реляционной алгебры. 40 и даже 50 лет назад в первичном «бульоне» зарождающейся IT индустрии «варились» только NoSQL-продукты. И что самое интересное – продукты, рожденные в те сложные времена, живы до сих пор и прекрасно себя чувствуют.
Одним из таких продуктов стала СУБД GT.m, разработанная компанией Graystone Tehnologies в 70-80-х годах прошлого века. СУБД нашла широкое применение в медицине, страховании и банковской сфере.
В нашем банке мы тоже используем GT.m, и этот инструмент прекрасно справляется с обработкой большого количества транзакций. Но… Есть одна проблема: GT.m никакой для аналитики, в нем нет SQL, аналитических запросов и всего того, что делает финансового аналитика счастливым. Поэтому мы разработали собственный «велосипед» для репликации данных из GT.m в «реляционные» СУБД.
А вот здесь должна была быть картинка с летающим велосипедом
Всех заинтересованных приглашаем под кат.
Читать полностью »
