User
Занимаясь разработкой мобильных приложений под операционную систему Android уже более 7 лет, я успел поработать в разных частях мира в самых разных компаниях, от небольших стартапов до технологических гигантов и накопил некоторый практический опыт в области автоматизированного тестирования мобильных приложений, которым хотел бы поделиться в цикле статей.
Влияет ли размер приложения и команды на то, как мы его релизим? Давайте представим себе стартап. Проект и команда небольшие. В этом случае обычно не задумываешься о процессе релизов: сделал фичу — зарелизил.
А теперь представим большой проект, например, какое-нибудь банковское приложение, над которым работает много команд. Тут мы понимаем, что наверняка есть процесс, релизные циклы, «бюрократия». Без этого будет хаос. Но где то место, когда становится ясно, что пора такой процесс настраивать и у себя?
В этой статье расскажу, что при росте приложения Додо Пиццы стало для нас отправной точкой и заставило внедрить Release Train. В конце поделюсь результатами, помогло ли это.
Если ваш проект растёт, или вы по другим причинам часто спотыкаетесь в работе при релизе приложения, то надеюсь, что наш опыт пригодится и поможет эти проблемы решить.
Server-Driven UI (SDUI) — это подход для динамичного и гибкого пользовательского интерфейса, когда сервер посредством API сообщает приложению, какие компоненты и с каким контентом отображать. Он довольно популярен, и мы его тоже используем на многих экранах — помогает быстро выпускать фичи в продакшн.
В статье покажу, на каких экранах мы его применяем, и расскажу, как развивались у нас подходы гибкого UI, какие плюсы и минусы мы вывели из его использования. Сначала рассмотрим формы на динамических полях, контракты и тонкие моменты создания новых полей. Потом поговорим про динамические флоу, как за ноль калорий на стороне фронта добавлять новых провайдеров для проведения оплаты и закончим зависимыми полями. Всё это с примерами экранов мобильного приложения.
В текущем состоянии индустрии разработки подход к эффективности работы какой-то странный. Мы пользуемся не привязанными к жизни метриками, уповаем на локальные оптимизации и мучаем людей.
Всё может быть куда лучше, и эта статья предлагает методику непрерывного совершенствования эффективности разработки. Рассуждение построено на уже зарекомендовавших себя теориях, включая философию Деминга, теорию ограничений, бережливое производство и других.
Что может быть более полезно для будущего, чем образование?
Что может быть более полезно для образования, чем интерактивный QA-учебник состоящий из 42 модулей, 42 онлайн-тестов, 500+ страниц от менторов с суммарным опытом 100+ лет?
Что может быть более полезно для кошелька QA-студента, чем когда это всё бесплатно?
Этот учебник появился не потому, что миру нужен был еще один учебник по тестированию. Хороших QA-учебников предостаточно. Он появился, когда стало ясно, что и обучающимся самостоятельно, и, как ни странно, QA-преподавателям нужен несколько другой подход к обучению тестированию. Так появилась трехуровневая модель обучения, результатом которой этот учебник и стал.
Привет, человек, %хабраюзер%, %юзернейм%, программист.
Этот пост является оплотом ненависти. Так уж вышло. Но тебе, как программисту пора перестать оправдываться.
Простой и красивый синтаксис, множество библиотек под самые разные задачи и большое комьюнити делают Python одним из самых популярных языков программирования на сегодняшний день, который активно используется в data science и машинном обучении, веб-разработке и других областях программирования.
Когда я начал изучать питон, у меня возникло несколько вопросов.
Пытаясь уследить за всем многообразием метрик и срезов на дашбордах, можно легко упустить из виду важное изменение метрик, сигнализирующее о проблеме. И если вовремя не отреагировать, то можно лишиться аудитории или выручки. Расскажем, как мы автоматизировали оповещения о падениях (или нездоровых взлётах) продуктовых метрик, чтобы сразу оценивать масштаб проблемы в деньгах, и что это дало продукту. Наш опыт будет полезен в первую очередь аналитикам и руководителям продуктов.
Темы статьи:
- Фреймворк - это модель. И у нее есть некие допущения. Эффективность модели и зависит от допущений.
- Иванов Иван натягивает свой опыт на фреймворк, что же получится?
- Любая стандартизация призвана устранить изменчивость.
- Любой продукт является системой, потому что создание любого продукта имеет некоторую цель, а основное свойство системы — ее наличие. Продукты без цели не существуют.
- JBTD - для чего его лучше всего использовать
Кто про что, а я про баги.
В прошлом году я рассказывала вам про Багодельню — мероприятие, проводимое у нас в компании для чистки бэклога багов. Событие хорошее и полезное, но решающее проблему с багами разово. Мы провели уже шесть Багоделен, но количество участников постепенно снижалось и стало очевидно, что потребность в этом мероприятии начала отпадать. Основной причиной стало появление у нас Zero Bug Policy. О ней есть не так много источников на русском, где можно почитать и найти удобное решение для себя. В этой статье я расскажу про наш подход к теме и с удовольствием почитаю про ваш опыт в комментариях.
Примечание Wunder Fund: мы very early adopters Ноушена и большие его фанаты. Поэтому решили перевести нетипичную для нас статью о том, как он создавался, как рос, как развивалась его стратегия. В статье есть ряд интересных мыслей про развитие продуктов.
Что можно узнать о стратегиях роста бизнеса, в основе которых лежит продукт и формируемое вокруг него сообщество пользователей, проанализировав SaaS-стартап стоимостью 10 миллиардов долларов?
Продолжаем тему оформления документов по ГОСТам, начатую в статье «Оформляем приложения по ГОСТ 7.32 в MS Word и не только». На этот раз рассматриваем подходы к автоматизации форматирования больших текстов (более 500 страниц) в редакторе MS Word. Предлагаемые подходы применимы также в других редакторах, использующих стили, в частности, LibreOffice Writer.
”Если вам нравятся Руби, Свифт, Дарт, Эликсир, Эльм, С++, Питон или даже С, используйте их ради бога. Но выучите Кложур, и выучите его хорошо” — Дядя Боб (твит, а также твиты: 1, 2, 3).
Статей о Clojure написано много, цель этой — дать свое видение некоторых преимуществ языка для кросплатформенной разработки на Flutter. Ориентируюсь в первую очередь на dart-разработчиков, но статья может быть интересна всем, кто работает с Clojure и/или Flutter.
Привет. Сегодня хочу рассказать про то, как за кулисами устроена работа моего мини-проекта по ведению задач autofocus.su. В предыдущей заметке я рассказал про принципы, лежащие в основе метода Автофокуса. А тут будет скорее набор ключевых слов с короткими описаниями того, что и как связано между собой. Конкретная реализация будет отличаться в вашем конкретном случае, но направления для поисков будут понятны.
Лично мне часто не хватает какого-то скелета работоспособного приложения, чтобы было с чего начать. Надеюсь, что буду полезен.
Начнем с бэкенда.
В 2019 году мы почувствовали необходимость сфокусировать силы разработки на реализации наиболее ценных бизнес-проектов, а не всего подряд. Внедрили сквозное планирование от стратегии компании до продуктовых роадмапов и задач на команды разработки на квартал. Но на коммуникации при самом планировании и реализации фичей уходило слишком много времени.
Тогда мы запустили первые agile-поезда. Эксперимент оказался успешным: сократилось время выдачи полезной функциональности, увеличился фокус команд, была хорошая обратная связь от бизнеса. Поэтому сейчас все инженерные команды и сотрудники функциональных команд Quadcode работают в том или ином поезде. В статье подробнее расскажем, почему понадобилось переходить на новую модель, где мы на пути к продуктовому подходу и верхнеуровнево пройдёмся по процессам.
Сортировка – мощная функция, вместе с фильтрами помогающая клиенту легче найти то, что он искал. При этом ей часто отводится «роль второго плана» и уделяется меньше внимания.
Отсюда и множество кейсов с плохо проработанной сортировкой даже у топовых магазинов. Но есть и крутые примеры. Как всегда, учимся на чужих ошибках, изучаем хорошие идеи и применяем у себя.