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

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

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

В свое время я случайно узнал, что исключения в моём горячо любимом языке C# — и, как следствие, во всем .NET — не все ведут себя одинаково. Причём, что ещё гораздо интереснее, далеко не все и не всегда могут быть обработаны и перехвачены. Что, казалось бы, полностью противоречит интуитивному восприятию конструкции try-catch-finally. 

Изучая этот вопрос, я находил всё новые и новые исключения среди исключений, которые оказывались «сильнее», чем конструкция try-catch-finally. К тому моменту, когда мой список вырос до 7 пунктов, я внезапно осознал, что нигде не было такого места, где можно было бы найти их все сразу. Максимум — 2 или 3 случая, рассмотренных в одной статье. 

Это и подтолкнуло меня к написанию данной статьи. 

В статье я расскажу о том, как разрабатывать дизайн доступных (т. е. отвечающих требованиям доступности) компонентов, об основных руководствах по доступности и о ключевых моментах, на которые стоит обратить внимание, а именно: о порядке фокуса, о клавиатурном взаимодействии и об ARIA-атрибутах.

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

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

Эта статья — своего рода ‘cheat sheet’ для веб-разработчика. Она даёт представление о «программе-минимум» для создания веб-приложения, защищённого от самых распространённых угроз.

Знакома история, когда забыл сохранить предыдущую версию рабочего макета — и считай её и вовсе не было? Система контроля версий поможет избежать подобных ситуаций. Я работаю UX/UI-дизайнером в крупном проекте, где создание интерфейсов и разработка идут одновременно. В таких проектах важно держать все изменения версий макетов не только в голове, но и в самом рабочем файле, чтобы вконец не запутать команду разработчиков.

В этой статье я расскажу о плюсах и минусах инструментов контроля версий, с которыми мне приходилось сталкиваться в работе: подход семантического версионирования; история версий в Figma и новый (пока в бета-версии) инструмент в Figma — Branching («ветвление»).

Однажды мы поняли, что для качественной и быстрой реализации разносторонних требований пользователей нам срочно нужны плагины. Изучив разнообразие имеющихся платформ для их создания, мы выяснили, что наилучшим образом нам подойдет Managed Add-In Framework от Microsoft, потому что, во-первых, она позволяет создавать плагины на базе .NET Framework, во-вторых, даёт возможность обмена данными и пользовательским интерфейсом между плагином и приложением-хостом, и в-третьих, обеспечивает безопасность и версионность, что делает плагины надёжными.

Жизнь показала, что мы были правы — плагины работают, пользователи довольны, заказчик счастлив. Правда, у Managed Add-In Framework есть ещё одна проблема — недостаточное количество информации. Всё, что мы нашли — это скудная документация да несколько постов на StackOverflow. Но этот пробел я частично заполню, описав, как мы преодолевали те препоны, с которым столкнулись. Эта статья будет полезна в качестве быстрого старта для тех, кто тоже решит освоить MAF для создания плагинов на базе .NET Framework.

«Каждый уважающий себя блогер должен написать статью о RBAC. Каждый уважающий себя читатель должен написать в комментарии, что всё равно ничего не понял». С этой фразы началось мое знакомство с RBAC. И я имел прекрасную возможность узнать, что всё так и есть.

Но теперь я разобрался с тем, что RBAC такое, и готов рассказать вам. Более того, я создал на основе RBAC собственный продукт, позволяющий использовать RBAC-паттерн в Angular-приложениях. Но обо всём по порядку.

За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.  

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

Введение

Добрый день! Меня зовут Кирилл, и я DevOps-инженер. За свою карьеру мне не раз приходилось внедрять DevOps-практики как в существующие, так и в новые команды, поэтому хочу поделиться своим опытом и мыслями по поводу стратегий ветвления. Существует множество различных типов рабочих процессов, и чтобы разобраться что к чему, предлагаю рассмотреть пример создания нового программного продукта. 

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

Привет! Меня зовут Денис Александров, и помимо работы в качестве Android-разработчика, я уже более семи лет готовлю стажеров в разных компаниях и занимаюсь студенческими практиками. Мне приходилось и работать с перспективными студентами персонально, и проводить групповые стажировки с отсевом. Я собрал самые важные и полезные тонкости проведения стажировок для студентов, благодаря которым мы делаем наши стажировки максимально полезными и эффективными для всех ее участников.