16 декабря сего года, команда разработчиков ReactOS, спустя долгое время после последнего релиза (с последнего прошло почти полтора года) выпустила новую версию под номером 0.4.14. Это все еще альфа-версия.
В данной статье мы рассмотрим основные новшества как со стороны разработчиков, так и со стороны сообщества.
Наверняка у каждого хотя бы раз было такое желание, чтоб написать комментарий и получить массу лайков за него. Как никак, человек существо социальное и одобрение этого самого социума порой очень хочется. Но тут возникает вопрос: а что нужно написать, чтобы получить максимальное количество лайков? И для этого можно использовать машинное обучение! В любой непонятной ситуации применяй машинное обучение.
На самом деле, это довольно непростая задача, требующая не только обработки комментариев, но и определения контекста, в котором он размещён. Но никто же не заставляет нас собирать квантовый суперкомпьютер, верно? Для простого обзора можно обойтись и более простыми инструментами.
Итак, для начала нужно собрать данные для обучения. В качестве источника таковых возьмём площадку YouTube. Уж где где, а на YouTube полно самых различных комментариев. К тому же в сообществах популярных каналов очень распространены локальные мемы, то есть некоторые слова и словосочетания, имеющие некий знаковый символ в этом сообществе. Употребление таких локальных мемов при написании комментариев, теоретически, должно увеличивать количество лайков, а значит несколько упрощать нам задачу.
Ключевым параметром будет выступать, естественно, количество лайков комментария, а признаками будут, во-первых, сам текст комментария, а во-вторых, разница между датой публикацией видео и комментария, так как очевидно, что чем позже от даты выхода видео размещён комментарий, то тем меньше лайков он соберёт. По второму признаку могут быть исключения в виде видео годовалой или более давности, которые по какой-то причине YouTube начал выдавать в рекомендациях у пользователей, после чего в комментариях к оным видео начинается активность, но мы подобные брать не будем.
У меня, как у пользователя Тинькофф Инвестиций, часто возникали вопросы: какие акции за весь период торговли принесли мне наибольший доход; сколько всего я заплатил за обслуживание тарифа и прочие комиссии; какие акции в портфеле давно лежат и не приносят мне доход; как отсортировать акции в своем портфеле по какому-либо критерию.
Текущая аналитика брокера показывает лишь открытые позиции, а профиль в пульсе подсчитывает только общий процент, без конкретики. Это не дает возможность увидеть «настоящую» картину своего портфеля.
К примеру, покупаем 1 акцию по 1000, после падения до 900 усредняем еще одной акцией. Затем при отскоке до 950 продаем 1 акцию. В итоге оставшаяся акция в портфеле "горит зеленым" (образуется плюс +50 по правилу fifo), хотя фактический результат бумаги на данный момент будет 0 (без учета комиссий). Такое отображение бумаг в приложении может сбить с толку, и привести к неправильным решениям и большим потерям, при совершении множества сделок.
Идея вести дневник сделок в excel, или периодически копаться в налоговом/брокерском отчете, мне не понравилась. Зато приглянулась мысль - обрабатывать данные полученные из официального API.
Результатом стал онлайн-инструмент, в который легко загрузить историю операций. После чего она отображается в табличном виде, с которыми удобно работать.
В статье я продемонстрирую, как пользоваться созданным инструментом, и какие задачи решаются. Подсвечу некоторые особенности данных полученных из API.
Привет! Я Илья Назаров, менеджер отдела интернет-продвижения Digital Lab – студии веб- и мобильной разработки. Сегодня разберем просмотр геолокаций из Яндекс.Аудиторий в Excel и Power BI.
Большинство рекламодателей и специалистов по настройке рекламы знают, зачем нужны Яндекс.Аудитории. Один из самых востребованных вариантов – сегменты на основе геолокации. Что может быть проще? Рисуете на карте полигоны или загружаете адреса, указываете радиусы и задаете условия взаимодействия людей с локациями. ⠀
Через несколько часов аудитории готовы: они расскажут про ваш бизнес всем, кто подходит под критерии и пользуется интернетом. Но проходит время. Люди, входившие в аудитории, оказываются недоступны. Или вы получаете доступ к аудитории, созданной кем-то другим. И вот вы уже не помните и не понимаете, вокруг каких локаций и с какими условиями настроены аудитории, даже если они понятно названы. Знакомая ситуация?
Скорость загрузки сайта и правильное считывание страниц роботами поисковых систем — краеугольный камень для успешного интернет-магазина, за эти показатели борются разработчики. Оба фактора влияют на ранжирование в поисковой выдаче, а отдельно скорость предопределяет поведение пользователей.
Сейчас мы работаем над e-commerce платформой для большой сети розничных магазинов. Привычное для нас и клиента решение — магазин на базе Битрикса — не подходило для проекта. И мы обратили свое внимание на Nuxt.
Была у меня мечта - писать backend на C++. А вот разбираться в unix socket'ах, TCP, многопоточной/асинхронной обработке запросов и во многом другом совсем не хотелось. Не верил я, что до сих пор нет каких-то минималистичных фреймворков. И сегодня я вам расскажу, как можно просто сделать HTTP API микросервис на C++ с помощью фреймворка Drogon.
Современное представление о REST сильно отличается от концепции архитектурного стиля, описанной в диссертации его создателя, Роя Филдинга. В этой статье разберемся, как ограничения REST понимал их автор.
Привет, Хабр! Меня зовут Дима Бочкарёв, я IT-лидер стрима «Сквозные бизнес-компоненты ВТБ Онлайн». В этом посте я расскажу, зачем и как мы меняли архитектуру приложения в части истории операций клиентов, с какими проблемами столкнулись и как достигали цели «сделать всё хорошо». Подробности под катом.
В программировании очень популярен прием создания программных интерфейсов - API. Этот прием очень полезен, чтобы скрыть все тонкости реализации и не нагружать ими обывателя. Но бывают случаи, когда хотелось бы поддерживать в коде несколько API, которые выполняют одну и ту же задачу, причем с минимальным переписыванием кода. Например: поддерживать работу игры (движка) на различных графических API: DirectX, OpenGL, Vulkan. В данной статье предложение решение данной проблемы.
Привет, Хабр!
Предлагаю вашему вниманию небольшую историю о том, как я решил посмотреть, как действия воротил рынка акций могут быть обнаружены по общедоступным тиковым данным, если изменить способ анализа рыночных данных, и что из этого вышло. Продукт получил рабочее название AdvancedCharts или кратко ACharts.
Многие что-то слышали, некоторые даже пробовали, но лишь единицы рассказали о таком мощном и удобном инструменте автоматизации биржевой торговли, как TNIKOFF INVEST API. Полностью раскрыть все возможности API или написать полноценного робота в рамках одной статьи – непосильная задача, поэтому будем двигаться постепенно, не перегружая мозг читателя чрезмерным объемом информации.
Если разработка программного обеспечения не входит в сферу ваших интересов, но слова "акции" и "брокер" не являются чуждыми, то загляните под кат ради интереса, где можно будет узнать о том, что тикер неуникален, а также о таких идентификаторах, как ISIN и FIGI, кроме того, в конце статьи будет доступен для скачивания свод инструментов, доступных у брокера TINKOFF. Чуть не забыл, еще и про всеми любимый Agile немного можно почитать.
Свою первую апишку я написал лет 7-8 назад и это был первый блин. В целом этот блин прошел кучу испытаний и модернизаций и получилось, что то вполне вменяемое. Даже сейчас я понимаю, что это ядро актуально и его можно развивать дальше и оптимизировать к текущим реалиям (пока нет подходящего проекта).
Как можно догадаться это было Rpc. Наверно стоит начать с того, что я выделил ряд слоев (какие то можно опустить, какие то добавить).
Сталкивались ли вы с задачей построить Enterprise-grade-приложение из десятков приложений, слабо связанных друг с другом, разрабатываемых разными командами, с разными моделями релиза?
Мы хотим поделиться опытом, как решили эту задачу в Netcracker. Как в этом помогла концепция Service Mesh и идея применить «микросервисную модель» и к структуре Service Mesh. Мы реализовали Non Uniform Service Mesh (NUM), который представляет собой продукт и набор паттернов его применения.
Сама статья основана на расшифровке выступления на SaintHighload 2021 в Питере Алексея Ефимова, системного архитектора Netcracker и руководителя отдела Cloud Core. Ссылка на запись — в конце статьи.
Продолжаем цикл статей, посвящённый основам Django Rest Framework. В предыдущей статье мы подробно рассмотрели, как сериалайзер валидирует входные данные.
В этой статье мы закрепим теорию на простом примере, а также затронем те вопросы, которые не успели рассмотреть раньше:
ForeignKey-поля модели;save сериалайзера.А ещё мы напишем контроллер, который будет обрабатывать запросы к API на создание записи в БД.
В данной статье речь пойдёт о том, что такое инструмент MLflow и из каких компонентов он состоит. Как работает данный фреймворк, в каких случаях рекомендуется его использовать и какие проблемы он позволяет решить. Затронем основные плюсы и минусы данного инструмента.
Самый распространённый стандарт для обмена информацией внутри приложений — это REST API. Его все любят, но знают, что он не идеален. В этой статье обсудим его альтернативу — GraphQL. Мы расскажем, в чём преимущество GraphQL, как выглядят запросы и с чего начать.
Кажется, что жалобы на колл-центр - это одна из самых популярных тем всех форумов, когда дело доходит до общения с клиентами. Почему? Все дело в том, что людям намного проще нахамить, нагрубить, проигнорировать, находясь по другую сторону экрана, чем сделать это при личной встрече.
Несмотря на то, что данный вид связи и передачи информации наиболее комфортный и быстрый, он также приводит и к нехватке контроля и, следовательно, к "распущенности" операторов. Однако первый личный контакт клиента с компанией, выходящий за рамки красиво оформленного сайта, происходит именно в чате. Именно поэтому от того, как быстро, вежливо и четко ответит оператор, зависит останется с вами клиент или уйдет к вашему конкуренту.
В прошлой статье мы рассказывали, как у нас в банке работает платформа WSO2. Мы предоставляем ее как сервис, как интеграционный слой, следим за его стабильностью, а разработкой на платформе занимаются уже команды из подразделений. Они работают на разных стеках — Java, C# и т.д. — и обращаются к нам по необходимости за консультациями. Проанализировав обращения, мы решили сделать несколько инструкций по разработке на WSO2, которые охватили 80% всех вопросов, что приходят от команд. Теперь хотим поделиться наработками со всеми и начнем с разработки REST API-сервиса на WSO2. Бонус для самых терпеливых — в конце поста.
Наверняка каждый слышал о грандиозной идеи Павла и Николая Дуровых об интеграции крипто кошелька, основанного на созданном ими же блокчейне TON (Telegram Open Network) в мессенджер Telegram. Накануне запуска, SEC США объявила о чрезвычайных мерах против Gram (криптовалюта) и выдала временный запретительный судебный приказ в отношении Telegram.
Кадр из мультфильма «Смешарики: 132 серия (Пылесос)»
При проведении различной ad-hoc аналитики или же создания интеграций между DS решением и внешними системами очень часто приходится использовать REST API для получения данных. Ситуация, когда все помещается в один запрос — идеальна, но редка как единорог. Как правило, приходится тянуть большие объемы, тянуть по частям и в режиме многоходовок, возможно, с использованием курсоров. Внешняя система может лечь при большой нагрузке или же там включатся механизмы пропуска запросов (троттлинг). Вопросы «почему у меня не работает» и «как мне сделать, чтобы работало» возникают с завидной регулярностью.
Ниже приведен блочный разбор типового скрипта для получению данных из внешней системы через REST API. Его можно рассматривать как первое приближение решения задачи подобного класса.
Является продолжением серии предыдущих публикаций.