Привет, Хабр!
При разработке приложения мы столкнулись с проблемой правильной обработки Push (т.н. пушей) уведомлений на стороне клиента.
Ниже расскажу про метод его создания и подключения, сертификаты и возможности для пушей, приведу подробные примеры кода с пояснениями. Также поделюсь некоторыми тонкостями. Например, про логирование информации о получении пуша с применением опции keychain sharing, загрузку картинки в пуш-уведомление и изменение счетчика пушей.
Дизайнеры продукта получают тонны пользовательского фидбека по разным каналам. Это могут быть как результаты UX-исследований, так и тикеты от поддержки, замечания коллег, пожелания запилить ту или иную фичу от клиентов, бизнеса или маркетинга, отзывы и жалобы из сторов, сайтов с рейтингами или соцсетей. И даже это – лишь малая часть списка.
Фидбек от пользователей это всегда ценные вводные. Но если относится к этим вводным без достаточной доли осторожности, собранный фидбек может превратиться в бессмысленный список задач в бэклоге, в котором эти задачи приоритезированы по принципу «кто громче и чаще орал». Что, в свою очередь, приводит к распылению ресурсов команды, а сам продукт становится результатом скорее компромисса, чем результатом чёткого видения. На пользовательский опыт такой процесс разработки тоже влияет – есть немаленькие шансы, что он будет неконстистентным и непродуманным.
“Что с этим делать?” - спросите вы.
Привет, Хабр!
Думаю, для вас не секрет, что в последние годы контейнеризация вышла в лидеры на DevOps благодаря своим возможностям, включая эффективное использование ресурсов и гибкость. Так что Microsoft и Docker потратили немало времени на создание удобной среды, в которой можно было бы провести запуск приложений .NET внутри контейнеров.
Наша команда в разработке использует Kubernetes кластеры, в которых разворачиваются контейнеры на базе Linux систем с различными .Net приложениями и сервисами. Так что в какой-то момент мы встали перед вопросом, как проводить мониторинг не только контейнеров, но и дампов.
За помощью мы обратились к всемогущему интернету, и после нескольких часов изучения данного вопроса, наш выбор пал на использование “sidecar” контейнеров.
Почти каждый инженер при разворачивании web проекта сталкивается с вопросом использования и реализации SSL-сертификатов. Я так точно с ним столкнулся)
Обычно в стартапах используются бесплатные сертификаты, например, от тех же Lets Encrypt. Но, как и любое бесплатное решение, оно имеет ряд неудобств и ограничений. Все ограничения подробно прописаны на странице поставщика сертификатов, где вы и можете с ними ознакомиться: https://letsencrypt.org/docs/rate-limits/
И регулярно сталкиваясь с этими ограничениями, я пришел к своей собственной настройке решения с Let’s Encrypt сертификатами, которой и хотел бы с вами поделиться.
Речь пойдёт об инфраструктурном решении на базе Kubernetes кластеров в контексте облачного провайдера Azure.
В компании SDVentures мы часто используем на проектах связку React + RxJS. Это довольно таки нетрадиционная связка, так что о ней мало что можно найти в интернете. Поэтому постараюсь рассказать о том, почему мы с командой стали её использовать и чем это может быть полезно вам.
Для меня, как и для моей команды, важна скорость разработки и ее качество, именно поэтому особое внимание я всегда уделяю выбору хорошей системе мониторинга.
В основном я занимаются разработкой новых фич, выпуском обновлений, поиском и устранением ошибок. Как и вам, мне важно понимать как ведет себя разрабатываемая система в контексте ресурсов и нагрузок. Именно поэтому нужна грамотная и качественно настроенная система мониторинга. Одной из таких, на мой взгляд, как раз и является система Datadog, о преимуществах и возможностях которой я хотел бы рассказать подробнее.
Если вы решили посвятить свой нелегкий путь разработчика React Native, то почти наверняка уже столкнулись с проблемой автоматического растягивания текста. Или (спойлер) столкнетесь с ней в ближайшем будущем. Немало часов я провел на форумах для поиска универсального решения. Меж тем, вводных для авторесайза текст-компонента в мобильных приложениях может быть великое множество - используемая платформа, утвержденный дизайн, который должен быть одинаковым на всех девайсах, анимации, размер девайса, объем текста, размер шрифта и т.д. Готовое универсальное решение нам не удалось обнаружить даже на любимом https://stackoverflow.com/. Поэтому каждый программист справляется с проблемой автоматического ресайза текста по-своему.
Сегодня, опираясь на опыт разработки мобильных приложений в SDVentures, я смог выделить три оптимальных решения в зависимости от задачи, которыми и поделюсь с вами.
Итак в материале ниже расскажу о задачах, которые решает тот или иной вид авторесайза, их плюсы и минусы, опишу готовые библиотеки для каждого решения. Поехали!
Для визуализации данных и метрик ИТ-инфраструктуры, мы используем Zabbix+Grafana, DataDog, ElasticSearch+Kibana, специализированные пакеты мониторинга для разных СУБД. Но эти инструменты не всегда дают необходимый результат. Поэтому мы дополнительно создали мониторинг, который делает ровно то и ровно так, как надо.
Этот материал будет полезен тем, кто хочет улучшить свою систему мониторинга, кого не устраивает гибкость существующего инструмента, цена или поддержка.
Как мы ускорили автоматизированное тестирование в большом проекте
Мы делаем масштабные приложения на высококонкурентном рынке. Чем выше скорость обновлений и внедрений новых фич, тем больше зарабатывает компания и её сотрудники. Поэтому мы постоянно оптимизируем время прохождения автотестов. Изначально автоматизированное тестирование одного приложения занимало 16 часов. Мы уменьшили это показатель до 8 часов. В статье рассказываем, какие практические шаги сделали, чтобы добиться такого результата.