Зачем развивать таланты? «Человек пришёл на определенную позицию, у него есть должностная инструкция и задачи, так пусть он берет все это и доказывает, что мы ему не зря деньги платим». Однако, чем лучше раскрыты таланты сотрудников, тем больше вариантов для дальнейшего роста компании. В этой статье я, Татьяна Алексеева, Head of Customer Success Department в Social Discovery Group, поделюсь лайфхаками о том, как развивать команду и смотреть на сотрудников не только с точки зрения должностных инструкций. Находить и развивать таланты — мое творчество в роли руководителя. Поэтому мой департамент является «поставщиком» талантливых кадров для других департаментов.

Всем привет! Мы - отдел бизнес-поддержки (БП) в Social Discovery Group. В этой статье расскажем, как мы повторили шестой подвиг Геракла, очистив доску от 1500 тикетов, которые накопились за 4 года. 1500 задач - это больно. Тикеты кочевали из спринта в спринт, заказчики ежедневно запрашивали статус по задачам, а мы испытывали стресс от переработок и от того, что не можем дать апдейты. Мы поняли, что нужно менять процессы в отделе и применили подход STATIK, который навсегда избавил нас от бесконечной очереди задач. 

Привет, Хабр! Мы участвуем в создании Social Life 3.0 и поддерживаем мероприятия по ее развитию. Одним из таких ивентов стал глобальный Web3Souls Хакатон, который проходил в декабре в метавселенной. В статье рассказываем о Хакатоне и четырех победивших проектах, которые разделили между собой 10000 USDT. За неделю команды должны были разработать MVP проекта, который использует технологии DeSoc и SBT.  

Один из способов монетизации social discovery продуктов – виртуальные подарки. Я расскажу, как мы в Social Discovery Ventures экспериментировали с ценами на подарки, проводили исследования, внедряли новые фичи, что мы планируем внедрять дальше – и, наконец, может ли виртуальный подарок быть для клиента ценнее реального, и если да, то почему.

Создать нового пользователя для теста продукта - простая задача для любого qa: необходимо просто прокликать форму регистрации. Но что, если протестировать нужно юзера с годовой историей переписок? Или проверить, как работают фишки видеосервисов на тех, кто попал в конкретную группу A\B тестинга? Ниже - история о том, как мы устали создавать таких пользователей вручную и разработали тулу, которая делает это за нас.  

UX основан на психологии пользователя более чем любой другой вид дизайна - юзер должен понимать назначение каждой отдельной иконки. А в дизайне приложений для знакомств роль психологии еще больше. Ведь UX должен превратить онлайн пространство для дейтинга в комфортную зону для миллионов пользователей в поиске второй половинки. Да, функционал может немного отличаться, но в итоге основная цель большинства этих приложений заключается в том, чтобы пользователь сделал выбор, основываясь на своем впечатлении от внешности другого человека. Но новое поколение ждет иного подхода - перевести внимание с внешности пользователя на его личность.

На пути от наблюдаемой системы до пользователя DataDog (здесь и далее - DD) метрические данные неизбежно проходят несколько этапов агрегации. Это означает, что в момент чтения метрик пользователь DD оперирует не конкретными значениями, а их агрегатами. Теоретически возможно записать в DD метрики таким образом, чтобы они в итоге не были подвержены агрегации, но это не имеет смысла и противоречит самой концепции DD.

Недавно ETIAS (European Travel Information and Authorisation System) составил рейтинг лучших городов для цифровых кочевников. В отличие от остальных рейтингов, которые рассматривали именно страны, в нем участвуют также города и даже континенты. Специалисты компании проанализировали 154 города и ранжировали их на основе скорости интернета, стоимости жизни, уровня преступности, количества коворкингов, средней стоимости рабочего места в месяц.

Первые места в рейтинге заняли Мадрид, Прага, Тбилиси и Берлин. В европейских городах созданы наилучшие условия для жизни цифровых кочевников: там уже давно позаботились о специальной визе, организовали комфортные коворкинг-центры, да и культурная составляющая часто привлекает номадов со всего мира. 

Сами номады предпочитают проверенные направления. Это подтверждает и сообщество NomadList, в котором путешественники делятся своим оценками. Если верить информации на сайте, то наиболее популярными направлениями сейчас являются Турция, Грузия, Португалия и Германия. 

Про жизнь цифровых кочевников в Европе написано уже много статей и обзоров, полезных советов. Можно сказать, что европейский континент исследовали вдоль и поперек. Но что можно сказать о новых, малоизученных направлениях? 

Мы поговорили с сотрудниками Social Discovery Ventures, которые выбрали нестандартные локации для своих путешествий и попросили поделиться своими впечатлениями.

Привет, Хабр!

При разработке приложения мы столкнулись с проблемой правильной обработки 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 часов. В статье рассказываем, какие практические шаги сделали, чтобы добиться такого результата.