Этот пост о том, как можно решить задачу разбора строки по контектстно-свободной грамматике с помощью SMT-решателя. Здесь будет введение в тему, описание принципов работы и ссылка на github с работающей программой.
В самом начале у нас в Самокате была задача — внедрить практику нагрузочного тестирования на каждый релиз, чтобы минимизировать проблемы с производительностью на проде. А еще сделать это не потратив все деньги мира, ну и желательно внедрить это не за пятилетку. И вот где-то тут начинается немного магии Поэтому давайте оденем поварские колпаки, возьмем котел и попробуем приготовить PerfOps-инженера который должен нас спасти.
Меня зовут Кирилл Юрков, я SRE-тимлид Samokat.tech. Сегодня поговорим про нагрузочное тестирование. Про то, как мы решали обозначенную проблему, какие грабли нам попались, и какие трудности удалось преодолеть.
В этой статье я расскажу про исключительную ситуацию, которая произошла с одним исключением в продакшене нашего Android приложения.
Какой есть общий недостаток у мобильной, front-end и back-end разработки и иногда распила микросервисов? Дублирование логики. Очень часто я видел статьи или новости, где одна команда мобильных разработчиков ждет другую, чтобы выкатить релиз. И если с мобильными версиями более-менее все понятно и есть решения, то что делать с браузером? Очень часто логику работы приложения нужно поддержать и там.
Что делать, если хочется писать нативный код и при этом не иметь дублей реализации — на этот вопрос я постараюсь ответить подробно в данной статье. В процессе чтения можно будет познакомиться с технологией Kotlin Multiplatform и создать полноценный проект всем известной игры «Крестики-нолики» на трех самых популярных платформах Browser (JS), iOS (Swift) и Android (Java) с общей логикой на Kotlin.
Всем привет. Как вы все знаете после определенных событий у нас случился ресурсный кризис. И появился запрос на оптимизацию потребляемых ресурсов.
Темой и станет оптимизация потребления ресурсов микросервисов и уменьшение времени выполнения наших запросов.
Я думаю сейчас не осталось людей, незнакомых с корутинами в Kotlin. Волшебный инструмент, согласны?
Всем привет! Наверняка каждый Android-разработчик хоть раз сталкивался с проблемой скорости сборки своего проекта. После нехороших слов в адрес кодогенерации, покупок более мощного железа, многочисленных попыток распилить проект на небольшие параллельно собираемые модули и прохождений всех стадий торга мы продолжаем искать решение этой проблемы. К счастью, за годы развития и в Gradle, и Android Gradle Plugin (AGP) появилось много полезных штук для ускорения сборки, о которых я расскажу дальше.
Несмотря на шутку в адрес многомодульности, это действительно полезный подход, но для большого проекта с богатой историей модуляризация может быть очень сложным процессом. Поэтому пока давайте посмотрим, что можно сделать без больших болей на уровне Gradle и AGP.
Я расскажу на примере мобильного Яндекс Браузера. У нас было ~150 Gradle-модулей, ~2 млн LoC на Java/Kotlin, десяток Gradle-плагинов, тысячи строк кода в buildSrc и лёгкая дрожь от вопроса, сколько ещё может переварить билд-система. Не скажу, что это всё было категорически необходимо, но к написанным строчкам кода надо проявлять уважение.
Это промежуточная часть туториала о том, как можно создавать телеграм ботов на базе plagubot фреймворка и tgbotapi библиотеки. Конкретно в данной получасти речь пойдет про достаточно простой (по меркам будущих частей) плагин для регистрации команд на старте и их установке/очистке далее в рантайме
Всем привет! Меня зовут Степан Кашинцев, я руководитель группы разработки в Waves Enterprise, а конкретно — подразделения, отвечающего за создание децентрализованных приложений, реализующих процессы реального бизнеса на базе нашего блокчейна. В этом посте я хочу рассказать о нашем SDK для JVM-языков программирования, с помощью которого каждый Java/Kotlin-разработчик сможет попробовать себя в создании блокчейн-приложений.
Управление доступными ресурсами в облачной среде по запросу – тема, которая бывает очень непростой. Но эта работа стоит того, поскольку вы сможете использовать ресурсы гораздо эффективнее. Поэтому многие компании и проекты решаются мигрировать на облачные платформы, в частности, на Azul, AWS, Google Cloud или другие. С точки зрения программиста, есть одна истина, которая сохраняется и в облаке: рекомендуется понимать поведение и ограничения того JVM-приложения, что вы развернули (или не приложений, а подов, минимальных развертываемых единиц в Kubernetes). Платформа Java является многопоточной, и, даже если вы не собираетесь использовать какие-либо доступные для этого API, платформа все равно порождает множество потоков-демонов, работающих в фоновом режиме. Такие потоки нужны не только для очистки и подхватывания неиспользуемой памяти. Они относятся к платформе, а что насчет фреймворков? Фреймворки Java пытаются обслуживать большие эксплуатационные мощности; следовательно, инициируется работа множества вспомогательных потоков. Ниже мы немного заглянем под капот. В этой статье будет подробнее рассмотрено, как устроены популярные фреймворки Quarkus и Spring-Boot, сколько потоков они инициируют, чтобы обслужить все результаты. Давайте вместе пробежимся по примерам и для начала разберемся, какова разница между мониторингом и профилированием.
Привет, меня зовут Юрий, и я фулстек-разработчик в DataLine. В компании занимаюсь созданием и развитием внутренних и внешних ИТ-сервисов: Сервисдеска, мастер-справочников, учета оборудования.
Но, как говорится, каждый разработчик в жизни должен сделать 3 вещи: развернуть дерево, распарсить DOM и вырастить своего чат-бота. О последнем и поговорим: расскажу, как делал своего первого чат-бота для нашего Сервисдеска, какие задачи и как решал, с какими трудностями и способами преодоления столкнулся.
Статья посвящена ускорению скорости сборки флейворов и разных типов сборки монолитного проекта с помощью многомодульности и кастомного файла конфигурации.
TLDR: используем имя переменной при инициализации ее значения
Привет Хабр! Меня зовут Леонид Иванькин, я ведущий Android-разработчик в МТС Digital, работаю над приложением Мой МТС. В этой статье – сложные и не очень задачи, чтобы проверить, насколько хорошо вы разбираетесь в операторах для списков. Готовы испытать свои скиллы? Тогда переходите под кат!
Всем привет! Я Даниил, java разработчик в Just AI, и в этой статье я расскажу, как мы столкнулись с проблемой backtracking’а в регулярных выражениях и как ее решили с помощью библиотеки re2j.
Привет! Мы написали свою систему диплинков на основе кодогенерации. В этой статье поговорим, как мы упростили работу с диплинками и смогли отловить устаревшие, добавили мониторинг и как собрали все диплинки в одной статье в конфлюенсе.
Диплинк — это uri на конкретный ресурс в приложении. Они нужны бизнесу, чтобы упрощать пользовательский опыт. Так вместо нескольких переходов внутри приложения диплинки позволяют направить пользователя на определённый экран в один клик (польза для пользователя) и снимать статистику (польза для бизнеса). Например: на внешней площадке компания разместила баннер, в котором предлагается заказать виртуальную карту, пользователь может кликнуть по баннеру и сразу попасть на экран заказа карты, а бизнес сможет оценить, какая из площадок более эффективна.
Самая большая проблема — это проблема безопасности. Объясню на примере активити, которая открывает веб-страницы. Активити открывается по диплинку, в нём указывается URL в качестве параметра. Один из вариантов атаки — когда злоумышленник может заставить пользователя пройти по диплинку с URL на вредоносный сайт и таким образом провести атаку. Ещё одна из возможных проблем — на некоторых экранах нам нужно валидировать параметры, а это иногда занимает значительную часть активити. Было бы хорошо вынести валидацию в отдельное место.
Ещё у нас бывали случаи, когда маркетинг запускал промо-кампании либо с диплинками, в которых содержались ошибки, либо с устаревшими диплинками, которые уже не поддерживались, и мы могли об этом даже и не узнать. А при заведении новой кампании маркетинг обращался к разработчиками за диплинками и поиск занимал некоторое время. Если разработчик помнил название экрана и диплинк без параметров, то его можно было быстро найти, а если название экрана сразу не вспомнилось, то алгоритм поиска примерно такой: сбилдить проект -> пройти на нужный экран -> посмотреть в логах, какая активити открылась -> пойти в манифест для получения диплинка -> открыть исходных код активити для сбора входных параметров.
Посмотрев на это, мы поняли, что нам нужна единая точка обработки, анализа, мониторинга, и решили выбрать инструмент аннотаций и кодогенерации. Сейчас объявление диплинка у нас выглядит следующим образом.
Привет, Хабр.
Пару месяцев назад мой товарищ предложил создать коллекцию NFT и загрузить на opensea.io, идея мне показалась интересной и …
Привет! Мы в QIWI довольно давно применяем микросервисную архитектуру, но ее понимание не всегда было одинаковым: оно менялось со временем и эволюционировало. Наши первые микросервисы были достаточно большие по объему, но сейчас мы создаем сервисы гораздо меньшего размера с более узкой и ограниченной зоной ответственности.
Часто такой сервис отвечает за конкретную небольшую фичу в нашем продукте (или вообще за часть фичи), или же за часть какого-то большого процесса. Нам такой подход нравится, поскольку микросервисы имеют независимые жизненные и релизные циклы, мы можем релизить фичи независимо друг от друга. Кроме того, различные команды могут работать в рамках одного продукта параллельно над разными фичами, не мешая друг другу и не сталкиваясь лбами. Это даёт нам возможность независимо масштабировать микросервисы и гораздо быстрее проверять гипотезы. В общем, плюсов много.
Сейчас будет «Но», правда?
Но в системе, которая состоит из большого количества маленьких взаимодействующих компонентов, становится критически важным такое качество, как наблюдаемость. Нам нужны как некие высокоуровневые метрики, показатели, чтобы видеть, как система живет в целом, так и для каждого компонента, для каждого нашего микросервиса —нужно видеть его текущие рабочие показатели и получать уведомления, если эти показатели выходят за пределы нормы. Поскольку новые фичи мы делаем часто, то и новые микросервисы мы разрабатываем часто, получилось так, что настройка дашбордов и конфигурация алертов превратились в такую рутину, которая отнимает существенную часть времени. Так что всё это хотелось бы автоматизировать.
Допустим, у нас есть MediaRecorder. Он должен уметь записывать видео, аудио, или и то и другое. При этом, параметры для видео- и для аудиозаписи, конечно же, отличаются.
Конечно, для решения этой проблемы, можно просто использовать обычный Builder (см. MediaRecorder в Android, там так и сделано), но тогда возникает две проблемы:
Для записи видео требуется указать набор параметров, который становится необязательным, если мы записываем только аудио (и наоборот), и это надо как-то контролировать.
Один параметр может "тянуть" за собой другие. К примеру, если мы укажем noiseReduction = true, то нам следует указать и noiseReductionLevel, либо ни то, ни другое. При реализации "стандартного" Builder такие проверки можно написать, но выполнятся они уже будут при сборке объекта, то есть при выполнении, а хотелось бы, чтобы все параметры проверялись при компиляции.
В этой заметке описан такой сборщик.
Прошло уже какое-то время с момента, когда я публиковал свой первый туториал по tgbotapi и пришло время начать уже серию статей, которая должна разложить по полочкам, как можно разбивать логику Telegram ботов (а потенциально, любых ботов :) ) в целом и как это делать в вышеупомянутой библиотеке в связке с надстройкой PlaguBot.
