Привет! Меня зовут Амаль, я веб-дизайнер в Wrike: отвечаю за разработку веб дизайн-системы и веб-компонентов вместе с командой разработчиков и маркетологов. В этой статье расскажу о том, как с помощью А/B тестов и изменения некоторых деталей на веб-сайте нам удалось увеличить конверсию как минимум в 5 раз. Статья будет полезна, если вы планируете внедрить изменения в свою веб-систему и протестировать гипотезы по увеличению конверсии.
В этом году DartUP уже во второй раз прошел в онлайне, и это было круто! Мы снова слушали два потока докладов на русском и английском, неформально общались и участвовали в дискуссиях в SpatialChat, сражались и решали алгоритмические задачи в Code Kombat и обгоняли соперников в Wrike for Speed. В этой статье подводим итоги конференции и делимся видеозаписями всех докладов.
Переезд в другую страну требует определённой решимости, чай не за чаем сходить! Но когда на столь длинном пути стоит пандемия, очереди в консульство и мировая неопределенность, это одинаково тяжело и для людей, и для компаний. В статье я расскажу о взгляде с другой стороны: как мы перевозили сотрудников, прорывались через ковидные кордоны, открывали еще один офис в Европе и теряли розовые очки. И про то, сколько это стоит.
Привет! Меня зовут Мария, я DevOps-инженер в компании Wrike. В этой статье расскажу о работе DevOps-инженеров с командами разработчиков: как выглядит процесс взаимодействия, из каких этапов состоит и как построить его с нуля. Статья будет полезна, если вы часто меняете проекты и каждый раз вам приходится заново создавать документацию и внедрять базовые процессы в работу команды.
Прошу приветствовать одну из первых DI библиотек для Kotlin multiplatform — DI.kt.
Вы можете спросить: «А зачем нам ещё DI либы?». Долгое время полноценного DI для Kotlin Multiplatform не было. Существующие библиотеки — это сервис-локаторы (Koin, Kodein, Popkorn), которые не валидируют граф зависимостей во время компиляции. А это одна из важнейших фич многих привычных Java и Android сообществам DI библиотек и фреймворков. Чтобы принести эту фичу в Kotlin Multiplatform, я и написал DI.kt. Библиотека намного проще привычного нам Dagger — нет мультибиндингов и прочих концептов, которые делают его таким сложным в освоении (и периодически используются неправильно).
Если ваш проект с автотестами растет, то рано или поздно ставится вопрос о том, как централизованно управляться с этими тестами. Как найти время на поддержку тестовой документации? Как ее структурировать? Где хранить отчеты? Как избавиться от нестабильных тестов и быстро выявить ответственных за них? В Wrike мы смогли ответить на все эти вопросы и автоматизировать процессы, которые они затрагивают. В статье расскажем, как нам это удалось.
Привет, Хабр! 3 и 4 декабря мы проведем DartUP — онлайн-конференцию по Dart и Flutter на русском и английском. Вас снова ждет несколько потоков докладов: спикеры из Google и других компаний, а также разработчики тулинга для Dart и Flutter поделятся новостями об экосистеме и своим практическим опытом.
Качеством кода в тестах часто пренебрегают. Когда в совместной разработке участвуют десятки QA-инженеров, возникает острая необходимость ввести формализованные правила, чтобы все могли быстро ориентироваться в тестовом проекте. К тому же часто тесты пишутся по аналогии или копируются с небольшими изменениями. Когда счет тестов идет на тысячи, то код, написанный в плохом стиле, быстро распространяется. Для решения этих проблем в тестовом проекте Wrike мы уже больше двух лет используем связку инструментов PMD и Checkstyle. И она отлично работает. В этой статье хотим поделиться опытом по настройке этих инструментов, их использованию и кастомизации.
В предыдущей статье мы анонсировали Dart Code Metrics — инструмент статического анализа кода. Сегодня я расскажу про новые возможности, которые появились в Dart Code Metrics с выходом очередного мажорного обновления. Поговорим про появление команд, поддержку монорепозиториев, улучшения в интеграции с CI/CD, и, конечно же, про новые правила для анализатора. Теперь у инструмента появился сайт с документацией, его можно найти здесь.
Привет, Хабр! Несколько месяцев назад Wrike публично объявил об отказе дальнейшей разработки на Dart и переходе на новый стек.
Это было сложное решение. И, как это часто бывает во времена больших перемен, нам захотелось сравнить и провести параллели. А как происходила миграция у других компаний? Чем она была вызвана, и удалось ли завершить процесс перестройки без серьезных потерь? Мы попросили коллег поделиться своим опытом миграции на фронтенде, рассказать о всех сомнениях и трудностях, что встретились на этом пути.
В этом тексте мы подведем итоги панельной дискуссии в виде небольшого конспекта: тезисно и с цитатами. Полную видеозапись встречи вы найдете в конце статьи.
Программисты пишут код (удивил, да?) Если это пет-проект, то вы вольны делать со своим кодом все, что хотите. Но когда над одним проектом работает несколько человек или даже целая команда, рано или поздно встаёт вопрос о необходимости код-ревью. Кому отдать на ревью? Как ускорить этот процесс? Как равномерно распределять реквесты по ревьюерам? Вопросов много, а ответы не так очевидны. В этой статье расскажу, с какой проблемой мы столкнулись в команде автотестирования в Wrike, как у нас устроен процесс ревью и зачем нам понадобился самописный сервис.
Инъекция зависимостей во ViewModel — очень популярная тема для статей по всему интернету. Давайте посмотрим, какие проблемы могут скрывать популярные подходы, и разберемся, есть ли способ инжектить ViewModel с помощью Dagger без огромного количества кода или потерь валидации графа зависимостей во время компиляции.
Рекомендованные практики от Google, как правило, включают использование ViewModel в качестве базового класса для View Models (тех, которые в MVVM). ViewModel — отличная штука для сохранения чего угодно в случае поворота экрана: будь то View Model, Presenter или Router. Но можно ли получить все преимущества выживания при повороте без необходимости наследоваться от ViewModel напрямую?
Больно, дорого, стрессово, но порой необходимо. Миграция на новый стек (язык или фреймворк) — событие, которое всегда интересно пообсуждать, особенно, если происходит оно не в твоем продукте. 13 июля в 19:00 (Мск) мы соберем подискутировать всех, кто пережил или переживает перевод фронтенда на новые технологии. «А я вам говорил» и другие комментарии зрителей — приветствуются!
Отправляясь в отпуск, все берут с собой телефон для съемок, некоторые — хороший фотоаппарат или action-камеру. А кто-то — квадрокоптер. Дрон больше не роскошь, а средство, которое помогает запечатлеть прекрасные воспоминания о путешествиях. Рано или поздно пандемия закончится, и многие из нас поедут в Европу, прихватив с собой коптер для съемок. Но, к сожалению, это может привести к штрафам за его нелегальное использование. Давайте разберемся, как сделать всё по закону.
В этой статье расскажем о том, как в какой-то момент один из важных продуктовых компонентов превратился в неповоротливого монстра и собрал кучу эскалаций по перформансу от недовольных клиентов. А также о том, какие шаги мы предприняли, чтобы выправить ситуацию и не переписывать все с нуля. Ну или почти все. Статья будет интересна всем, кто разрабатывает сложные приложения с большим количеством вычислений на фронте и одновременно борется как за клиентов, так и за производительность.
«Ну наконец-то!» — услышал я от нескольких человек, когда сказал, что готова вторая часть статьи про видео в Zoom. Первая часть про подбор камеры для съёмки в Zoom вызвала дикий резонанс. До сих пор продолжается холивар о том, что же лучше — вебка за 20 тысяч или старая зеркалка (думаю, вы знаете ответ) и какое освещение купить за десятку, чтобы выглядеть как суперзвезда даже со стандартной камерой (не всё так просто). В этой части поговорим про то, что не требует никаких вложений, но точно улучшит ваше видеопредставление — софт.
В этом году Google I/O снова проходил в виртуальном формате. Как это было, например, 3 года назад, можно прочитать в прошлой статье. Привычка делать саммари интересных докладов для разработчиков у меня осталась, так что решил поделиться своими заметками после просмотра сессий и чтения блог-постов. Думаю, что это будет полезно не только внутри Wrike.
В первой части вы узнали, что по веским причинам мы были вынуждены выбрать новый технический стек для дальнейшего развития нашего продукта. Пора перейти к самому интересному: что же мы будем использовать вместо Dart?
Данной статьёй мы хотим пролить свет на технический стек Wrike: каким он был раньше и каким мы видим его в будущем. Мы расскажем о том, почему пять лет назад мы выбрали язык Dart основным для frontend-разработки нашего продукта и почему сейчас мы решили посмотреть в сторону других языков и фреймворков.