Четыре из пяти соискателей-QA хотят научиться работать с автотестами. Не все компании могут осуществить такие желания ручных тестировщиков в рабочее время. Wrike провёл школу автоматизации для сотрудников и реализовал это желание для многих. Я в этой школе участвовал именно как ученик-QA.

Я научился работе с Selenium и сейчас самостоятельно поддерживаю определённое количество автотестов практически без помощи извне. И, по итогам нашего совместного опыта и моих личных выводов, я постараюсь вывести ту самую формулу как можно более идеальной школы автоматизации.

26 сентября в питерском офисе Wrike прошел Flutter meetup. В преддверии второй русскоязычной конференции по Dart и Flutter – DartUP 2019 – мы собрались обсудить лучшие практики по разработке архитектуры приложений на флаттере и нюансы по работе с графикой и анимацией. За два года сообщество разработчиков на дарт и флаттер выросло до 2000+ человек, поэтому найти интересные темы и доклады оказалось не сложно.

Для тех, кто не смог прийти, мы публикуем видеозаписи.

Тема перемещения своего бренного тела из одной страны в другую раскрыта, казалось бы, со всех сторон. Кто-то говорит, что пора. Кто-то говорит, что первые ничего не понимают и совсем не пора. Кто-то пишет, как купить гречку в Америке, а кто-то – как найти работу в Лондоне, если ты знаешь только русский матерный.

Однако, как выглядит переезд с точки зрения компании, вопрос почти не освещён. А ведь в этой теме есть очень много интересного, и не только для больших начальников. Но бюджеты, headcount, метрики и прочее – это безумно скучно для разработчиков. Что же это такое — открыть офис за рубежом, зачем, почём и как? И, самое главное, как нашему айтишному брату извлечь из этого пользу.

_{Статья получается нереально большой, поэтому в этой серии ответ на вопрос: “Зачем?”}

Чем плохи ночные смены знают многие: для здоровья вредно, весь режим себе испортишь, и вообще ночью спать надо. «Напомни, почему ты работаешь в ночную смену?» – иногда спрашивают друзья. Вот что мы в команде поддержки Wrike обычно отвечаем:

4 года назад я с коллегой поехала на свой первый митап. Начальник не отпустил пораньше, поэтому нам пришлось доработать свои регламентированные часы и мчать на такси до места проведения митапа. Мы, как опоздавшие школьники, тихо пробрались на свободные места в самом конце зала и принялись слушать. Это был офис Wrike. Могла ли я тогда представить, что буду работать в этом самом месте? Определенно нет. Думала ли я вообще о смене работы? Тем более нет.


_{pitercss_meetup №24. 11 сентября 2018 в офисе Selectel, фотография Натальи Майстренко}

Мы в Wrike очень любим Dart и Flutter. На связке Dart+Angular пишем фронтенд основного продукта, SPA Wrike, а флаттер просто бескорыстно поддерживаем и создаем на нем внутренние тулы. Два года назад мы придумали русскоязычное сообщество дарт и флаттер разработчиков (сейчас в нем более 2000 человек), ежегодно проводим в Питере DartUP — большую конференцию по этим технологиям, выступаем с докладами, а 26 сентября решили организовать ламповый неформальный митап в Петербурге. Что на нем будет? Выступления ребят из сообщества, обмен знаниями, общение и, конечно, крафтовое Wrike Dart пиво, сваренное нами по этому случаю.

В четверг, 5 сентября в 19:00, Wrike в Санкт-Петербурге открывает двери для джуниоров, стажеров, студентов и начинающих инженеров.

Мы продолжаем рассказывать о ключевых качествах для успешного менеджера по продукту, по мнению продуктовой команды Wrike. В шестой (!) части данной серии мы пообщаемся с Антоном Стожко. Антон работает associate product manager 1,5 года, куда перешел из команды Customer Support.

Как попасть в большую компанию, если ты джуниор? Как нанять достойного джуниора, если ты — большая компания? Под катом расскажу нашу историю найма начинающих ребят на фронтенд: о том, как мы прорабатывали тестовые задания, готовились проводить интервью и выстраивали менторскую программу для развития и онбординга новичков, а также почему не работают стандартные вопросы для собеседований.


Я, пытаюсь приручить джуниора

В 2016 году уязвимость ImageTragick в библиотеке ImageMagick наделала много шума. Как способ снижения риска предлагалось использовать GraphicsMagick — форк библиотеки ImageMagick, нацеленный на более стабильный и производительный API. Оригинальная уязвимость CVE-2016-3717, обнаруженная stewie, позволяла злоумышленнику прочитать произвольный файл на файловой системе при помощи специально созданного изображения. Сегодня я рассмотрю аналогичную уязвимость в GraphicsMagick, обнаруженную мной в ходе анализа исходного кода библиотеки.

Когда в Android появился встроенный счетчик потраченного на приложения времени, я первым делом обратил внимание на социальные сети: Instagram, ВКонтакте, Facebook и Telegram. Получилось, что за неделю я провожу там около 10 часов. «Не критичные цифры», — подумал я, но свое название, «социальные сети», они полностью оправдывают. Это то, что цепляет, удерживает и иногда может даже травмировать. И, как и положено сетям, есть та часть, которая лежит где-то ближе к мутному дну, и где совсем не очевидно, что может пойти не так в случае неординарных событий.

Привет, Хабр. Я data-аналитик отдела маркетинга Wrike: занимаюсь сбором и анализом всех рекламных данных, моделированием LTV и другими техническими задачами, помогающими команде делать самую эффективную рекламу во всех источниках. Недавно я столкнулся с проблемой настройки сбора данных на AMP-страницах и обнаружил совсем мало информации по теме, поэтому решил рассказать вам, как справиться с этой задачей.

Мы продолжаем нашу серию статей о ключевых качествах успешного менеджера по продукту. Мы уже успели пообщаться с Антоном Даниловым, Юрием Голиковым, Дмитрием Орловым и Алексеем Коротичем. Сегодня будем говорить с Александром Беляевым. Саша отвечает за один из наиболее масштабных аддонов — Wrike Resource.

Приглашаем всех на Customer Experience Day, который пройдет 20 июня в 19-00 в петербургском офисе Wrike. Регистрация обязательна, участие бесплатное.

Мы ждем customer success- и продакт-менеджеров, sales-специалистов, аккаунт-менеджеров, студентов лингвистических вузов, желающих развиваться в сфере IT, и всех работников продуктовых компаний, которым небезразличен клиентский сервис.



На встрече в офисе Wrike в интерактивных форматах мы обсудим:

• как научиться продакт-менеджерам взаимодействовать с customer success-менеджерами и что делать если такой роли в вашей компании нет;
• как создать мотивированную support-команду,
• как удерживать клиентов и привлекать новых силами клиент-менеджеров и аккаунт-специалистов.

24 апреля в платформе Wrike произошло важное изменение: команда объявила публичный релиз новой фичи — «Spaces», в русской версии — «Пространства».
Цель Spaces — улучшить работу команд в таск-менеджере и упростить навигацию в продукте, сделав процессы органичнее и прозрачнее. Получилось ли у нас? Продолжайте читать и узнаете, как раскатывать серьезные обновления в большой компании и не облажаться, как обеспечить взаимодействие 30 скрам-команд и какие уроки мы вынесли из процесса разработки продукта, релиз которого обошелся нам потом и кровью немалыми усилиями и прорывным командным духом.

В конце марта в питерском офисе Wrike прошел Allure server meetup. В несколько часов удалось поместить концентрированную информацию по новому инструменту Allure server, по современным практикам работы с тестовой документацией и автотестами и по интересному опыту взаимодействия тестирования компании Wrike и нового вендора на рынке TMS систем.

Для тех, кто не смог прийти, мы публикуем видеозаписи докладов.

Всем привет! Меня зовут Костя, и я руковожу отделом верстки в компании Wrike.
В нашем отделе сейчас работает 10 человек, и все эти ребята пришли в компанию в разное время, у них различный опыт и задачи в отдельных командах. При этом все сотрудники — прекрасные специалисты, которые вдесятером умудряются закрывать потребности всего продукта в верстке.

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

Для тех, кому много букв, есть видео.

Титульная конференция крупнейшего гиганта рекламного бизнеса отгремела уже как неделю, а некоторые до сих пор пишут статьи. Так как всё, что можно было написать про программу и главные новинки, уже написано (привет phillennium), то что остаётся скромному посетителю? Только рассказать всё, что скрыто, обнажить тёмные уголки и понять, что вообще происходит в солнечной Калифорнии эти три дня в году.

Так получилось, что я был на предыдущей конференции и даже написал статью про это. Поэтому, с одной стороны, задача усложняется, ведь никто не хочет читать одно и то же два раза, а с другой, она усложняется ещё больше. Не хотелось бы превращать текст в отчёт в духе: «прирост посетителей: +20%, надои упали на 3%, настроение личного состава хорошее», поэтому давайте условимся: перед вами будет художественное описание личного опыта и немного объективной информации.

_{Внимание, это не детальный разбор программы, а своего рода виртуальный тур по конференции. Никто же не любит обманутых ожиданий, правда? Все доклады есть на YouTube}

Я стою перед стендом Wrike на DevPRO'19 и смотрю, как проходит очередная сессия Code Battle.

— А они жёсткие, раз сидят и код пишут, — говорит мне школьник, на вид девятиклассник.
— Ну да, есть среди них жёсткие ребята. Сам не хочешь попробовать? — отвечаю ему.
— Не, я не умею, в JavaScript все сложно очень.
— Ну приходи, как научишься. А пока можешь в наше судоку сыграть, там не надо кодить.
— А что это?

И я уже собираюсь пуститься в пространное комментирование правил, потом плавно перейти к исторической справке, влиянию игры на психическое здоровье и на культурный код в целом, но в Code Battle выявился победитель, и паренёк слышит от меня только «надо заполнить строки и столбцы так, чтобы в них не было одинаковых картинок». Не лучшее объяснение, но сейчас у нас определился чемпион: один из участников одержал пять побед, решив небольшие задачки на JavaScript быстрее своих оппонентов, а, значит, настало время вручать приз.

Я уже пытался лечить «механический» scrum (часть 1, часть 2, часть 3), а в этой статье постараюсь выписать универсальное лекарство от «подгорания». Само по себе «подгорание», «бурление» и т.п. — это хорошо, это значит вам не все равно (а ведь безразличие — это шаг к унынию, или, как принято в IT — к выгоранию). На тему вреда выгорания написано и снято много материалов, например: вот, вот, вот или вот.

Одна распространенная мудрость гласит: «Баттхёрты — двигатель прогресса». Но часто бывает так: пригорело => быстро принимается поверхностное решение, маскирующее проблему => решение воплощается в жизнь => пригорать продолжает. Другими словами, вместо того, чтобы разобраться и поставить диагноз, мы сразу приступаем к лечению. Попытаюсь это проиллюстрировать примерами.