Как составить резюме по методу бутерброда

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

1. Упаковка. Оформление

Ваш бутерброд должен выглядеть аппетитно. Обратите внимание на форматирование и длину текста. Постарайтесь отфильтровать самое важное. Убедитесь, что в тексте нет ошибок, а все ссылки — кликабельны.

2. Первый слой

Рекрутер должен найти ваше резюме среди десятка других. Для этого проверьте релевантность вашей должности и ее название: например, будет лучше указать общепринятое «руководитель проекта», а не «управляющий директор бизнес-единицы». Перечислите ваши основные скиллы и прошлые места работы. 

3. Начинка. Опыт работы

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

4. Срок годности. Актуальность

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

5. Реклама бутерброда. Сопроводительное письмо

Здесь можно рассказать подробнее о себе и о том, почему вы хотите работать именно в этой компании. Но не переусердствуйте с саморекламой :)

Еще больше советов и лайфхаков от HR — в этой статье. А мы ждем ваши резюме-бутерброды на hr@agima.ru.

Главные особенности новых версий Dart и Flutter

В конце прошлой недели вышло сразу два заметных релиза: Dart 3.3 и Flutter 3.19. Объединили самое интересное в один небольшой пост.

Что нового в Dart:

• Добавили Extension types. С их помощью можно оптимизировать код, который зависит от производительности.

• Интегрировали новую модель взаимодействия с библиотеками JavaScript и заодно добавили пока экспериментальную поддержку WebAssembly во Flutter Web.

• Google выпустил бета-версию Google AI Dart SDK. Так что теперь гипотетически можно интегрировать функции искусственного интеллекта в приложения на Dart или Flutter. Но России в доступных регионах пока нет.

Что нового во Flutter:

• Изменения в скролле. Тут завезли оптимизацию и гибкость в управление поведением.

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

• Adaptive Switch. Компонент выглядит и ведет себя как нативный на macOS и iOS, а в других случаях — как Material Design. При этом он не зависит от библиотеки Cupertino, поэтому у него один и тот же API на всех платформах.

Также недавно мы рассказывали про условные выражения в Dart, про анимацию переходов и про то, как быстро настроить GitLab CI/CD на Flutter-проекте. Подписывайтесь на наш блог, чтобы следить за новостями.

Каким был генеративный дизайн в СССР

Генеративный дизайн, то есть дизайн, созданный с помощью специальных устройств, появился задолго до чата GPT и Midjourney. Простейший пример — это калейдоскоп, а из совсем уж докомпьютерного прошлого — карты Таро. И там, и там принцип тот же, что и у нейросетей: человек решает свою задачу с помощью приспособления.

У нас же генеративный дизайн начали развивать еще в 20 веке. Называлось это кибернетическим искусством. Один из интересных его примеров — ASCII-арт. Это изображения, созданные с использованием символов, цифр, букв или знаков. Мы и сейчас применяем что-то наподобие в переписках — ¯\_(ツ)_/¯. Но в советские годы изображения были, конечно, сложнее.

Генеративное искусство развивалось в визуальной сфере, музыке и поэзии. С помощью ЭВМ в специализированных институтах могли создавать мелодии или разрабатывать аккомпанементы, писать стихи и создавать скульптуры. Правда, занимались им в основном отдельные энтузиасты. Поэтому к моменту распада СССР отечественное кибернетическое искусство начало забываться.

Больше про историю генеративного дизайна рассказываем в отдельной статье, а классные примеры — в телеграм-канале.

Особенности тестирования приложений на Flutter

Тестирование Flutter-приложений в базовых принципах не сильно отличается от тестирования нативных. Но есть несколько интересных особенностей:

• Все элементы Flutter-приложения — виджеты: это упрощает тестирование интерфейса и функциональности, обеспечивает единообразие интерфейса.

• Тестирование на Flutter быстрее: платформенно-специфические функции тестируются отдельно на iOS и на Android, а остальные — на какой-то одной.

• Flutter предоставляет собственные инструменты для тестирования виджетов и интеграционного тестирования.

Есть и сложности:

• Отслеживание трафика: Dart обычно использует высокоуровневые библиотеки для HTTP-запросов, и они инкапсулируют низкоуровневые детали сетевого взаимодействия — это затрудняет доступ или мониторинг данных.
  
  Проблема решается подключением прокси-сервера. Лучше всего добавить этот функционал в инженерную панель.

• При тестировании различий UI/UX на разных платформах мы замечаем типичные проблемы: анимация, свайпы и отображение системных диалоговых окон.
  
  Поэтому не стоит фокусироваться на всех кнопках. Лучше обращать внимание только на существенные различия. Тут помогает общение с сообществом.

Чтобы работать с Flutter-приложениями, мы используем FlutterDevTools. Это комплект инструментов для отладки и профилирования в экосистеме Flutter. Также применяем голден тесты, а для автоматизации — Appium. Подробнее про это рассказываем в отдельной статье, а про Flutter — в телеграм-канале.

Value Proposition: ключ к сердцу клиента

Value Proposition (VP) или ценностное предложение — это обещание ценности, которое мы даем клиенту. Это не просто список функций или характеристик продукта, а скорее ответ на вопрос о том, почему клиент должен выбрать именно наш продукт.

Мы все перегружены возможностями выбора, а четкое VP помогает выделиться. Это не только привлекает внимание клиентов, но и способствует их удержанию. Для создания крутого VP нужно:

• Понимать свою ЦА.
  Хорошо изучите тех, кому вы предлагаете свой продукт. Чем лучше вы понимаете потребности и боли конечных пользователей, тем точнее сможете формулировать предложение.

• Объяснить уникальность.
  Чем ваш продукт отличается от конкурентов? Определяем и подчеркиваем это.

• Обеспечить простоту и ясность.
  Предложение должно быть понятным и запоминающимся. 

• Сфокусироваться на пользе.
  Говорим не о продукте, а о том, как он решает проблемы или улучшает жизнь клиента.

Value Proposition — это не просто маркетинговый слоган, это основа стратегии продукта. VP должно отражаться в каждом аспекте продукта: от разработки до маркетинга.

Для формирования VP очень важно исследовать CX и UX, чтобы лучше понимать боли и желания клиентов. Это поможет сформулировать то самое VP, которое будет взывать к их сердцам и умам.

С удовольствием обсудим примеры удачных и неудачных VP в комментариях. А больше о цифровых продуктах — в нашем канале.

Сжатие графика проекта: 8 способов сэкономить время и ресурсы

Несколько приемов, которые помогут управлять временем и ресурсами на проекте с максимальной эффективностью:

1. Реорганизация задач. Пересмотрите порядок выполнения задач и найдите возможности для их оптимизации. Возможно, некоторые из них можно выполнять параллельно.
   

2. Увеличение ресурсов. Расширение команды или распределение дополнительных ресурсов могут ускорить выполнение задач.
   

3. Изменение приоритетов. Оценка важности и срочности задач позволит сконцентрироваться на более критичных для проекта, отложив менее важные.
   

4. Упрощение задач. Некоторые задачи можно упростить без ущерба для качества. Пересмотрите требования и найдите более оптимальные решения.
   

5. Сжатие времени в критических задачах. Задачи критического пути можно ускорить с помощью дополнительных ресурсов и внимания. Это может включать работу во внеурочные часы или выходные дни.
   

6. Применение Agile. Agile-подход позволяет гибко реагировать на изменения и фокусироваться на приоритетных задачах, ускоряя разработку.
   

7. Управление рисками. Идентификация и управление рисками может предотвратить задержки и их влияние на проект.
   

8. Пересмотр процессов. Иногда сжатие графика проекта требует пересмотра и оптимизации процессов внутри проекта или компании.

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

Как мы объединили два разных екома в одну CRM

Оба интернет-магазина — назовем их А и Б — годами работали самостоятельно, накопили много контактов и клиентов, а потом объединились в одну компанию. Чтобы выстроить продажи, им нужна была общая база данных. Но стек у магазинов отличался, и понадобилась наша помощь.

Помимо стека, были и другие ограничения:

Срок MVP: на всё про всё — полгода.

Бюджет: лепить огромного отказоустойчивого мастодонта мы не могли.

Удобство: нужен был сервис одного окна с понятным интерфейсом.

Поэтому мы остановились на Bitrix24. Первым делом определили, что должно быть в общей CRM и какие данные нам нужны. Потом на этапе ППО выбрали механизм реализации — процесс ETL (Extract. Transform. Load). Он состоит из трех этапов:

• извлечение данных из имеющихся баз,

• преобразование их под новую бизнес-модель,

• загрузка в новую CRM.

>> Подробно про каждый этап рассказываем в отдельной статье.

В итоге пришли вот к такой архитектуре: 

Как видим, у нас было три экстрактора: общий для магазина А и два отдельных для магазина Б (один для Kafka, другой для Json). Два трансформера — для каждого магазина свой, они выдавали одинаковые DTO и передавали их в лоадер. Дальше лоадер закидывал всё в B2B CRM.

В результате нам удалось выгрузить свыше 170 000 активных компаний и более 264 000 контактов из обоих интернет-магазинов.

Подробнее про кейс читайте в нашем блоге, а заодно подписывайтесь на наш телеграм-канал для тимлидов.

User Guides (руководство пользователя): нужны ли они вообще или это что-то на древнем?

Интуитивно понятные интерфейсы и ML успешно вытеснили пользовательские гайды. Но есть случаи, когда User Guides необходимы:

• Сложные продукты. Например, программное обеспечение для специалистов, комплексные системы управления и т. д.

• Инновационные продукты. Новые технологии могут требовать объяснений и инструкций в формате полноценного руководства.

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

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

2. FAQ и База знаний
   
   ✚ Доступность, структурированность информации
   ✔ Для продуктов с большой пользовательской базой и типовыми вопросами
   

3. Интерактивные туториалы
   
   ✚ Обучение в процессе использования, «обучение через действие»
   ✔ Для приложений и ПО, где пользователю важен быстрый старт работы
   

4. Чат-боты и виртуальные ассистенты
   
   ✚ Мгновенная помощь, персонализация общения
   ✔ Для сервисов, где важна оперативная поддержка пользователя
   

5. Сообщества
   
   ✚ Обмен опытом, поддержка со стороны сообщества
   ✔ Для продуктов с активными пользователями, готовыми делиться опытом и помогать друг другу
   

6. Инфографика и чек-листы
   
   ✚ Краткость и наглядность
   ✔ Для простых инструкций и напоминаний о ключевых функциях продукта

Больше о работе с цифровыми продуктами читайте в нашем телеграм-канале.

Что такое «авторента» и как она изменила нашу жизнь

«Авторентой» мы назвали инструмент для автоматизации расчета рентабельности.

Мы работаем по формуле «рентабельность всей компании зависит от рентабельности каждого проекта». Поэтому на показателе рентабельности завязана мотивация примерно 60% сотрудников AGIMA.

Чтобы получить бонусы, руководителям проектов и тимлидам нужно рассчитать рентабельность своих проектов в конце квартала. До «авторенты» закрытие квартала занимало до трех месяцев и мы всё считали вручную. Получалось долго, дорого, неэффективно и с кучей ошибок. Нам это надоело и мы создали «авторенту». 

• Справочник для «авторенты». Здесь ставки, роли, привязка пользователей FinPlan и таск-трекера.

• Таск-трекер с подсчетом отработанных часов.

• Finplan для управленческого учета.

• Harvester всё объединяет и проводит первые расчеты. 

• Дашборды тимлидов и РП, где они отслеживают экономику каждого проекта.

• Распределятор. Хранит данные по всем дашбордам тимлидов и РП и распределяет внутренние затраты между проектами.

Результаты:

• Теперь закрываем квартал в среднем за месяц.

• Экономим сотни часов на расчете рентабельности.

• У нас есть сводные данные по рентабельности всех проектов в реальном времени.

• Появился полезный сайд-проект — дашборд простоев, — где видим количество «потерянных» денег.

• Выявили много читов, багов и недоработок системы управления.

Полная версия статьи тут. А больше полезного о рентабельности, метриках и планировании ищите в нашем телеграм-канале для агентств.

Мнение: почему мультиплатформа Kotlin не приживется в мире разработки

Спойлер: из-за нелюбви к изменениям и дефицита специалистов.

Наш руководитель направления Flutter и iOS Саша Ворожищев делится основными тезисами статьи о судьбе Kotlin Multiplatform Mobile (KMM). Автор статьи — разработчик Донн Фелкер (Donn Felker) — не пророчит KMM мировой славы. И вот почему.

• Люди не любят что-то менять. Особенно программисты. Редко встретишь iOS-разработчика, который перешел на Android. И наоборот.

• Кросс-платформа чаще не оправдывает надежд. Мы уже не раз наблюдали попытки создать кросс-платформенные суперхиты — взять к примеру Flash и ActionScript, Mono и Xamarin, —  но ни одна из этих технологий так и не покорила мир программирования.

Сейчас конкуренцию КММ может составить только Flutter. Пока это лучшее кросс-платформенное решение.

• Охота на единорога. Чтобы стать классным кросс-платформенным разработчиком, нужно разбираться не в одном, а сразу в нескольких языках и инструментах. Между тем, хороших программистов-полиглотов мало и они стоят дорого. Еще они часто выгорают, ведь технологии развиваются слишком быстро, а успеть сразу за всеми очень сложно.

• Универсальность != эффективность. Здесь стоит повторить, как важно подбирать правильные инструменты для решения конкретных задач. Мультиплатформа не может быть панацеей для всех проблем.

Полную версию статьи читайте тут.

А больше про технологии и разработку найдете в телеграм-канале Саши. Приходите, там интересно :)

Опросник SUS для измерения юзабилити

SUS (System Usability Scale) — это стандартизированный опросник для оценки общего юзабилити продукта.

Он состоит из 10 утверждений. Пользователи оценивают, насколько согласны с каждым из них. С SUS можно измерить, например, легкость использования, «понимаемость» и удовлетворенность продуктом.

Как это работает?

Например, наш продукт — это сайт. Предлагаем пользователям 10 утверждений о нем:

1. Я буду использовать этот сайт.

2. Сайт слишком сложный.

3. Сайтом легко пользоваться.

4. Мне понадобится помощь, чтобы научиться пользоваться сайтом.

5. Разные функции сайта правильно сгруппированы.

6. На сайте слишком много несоответствий.

7. Большая часть людей очень быстро поймет, как пользоваться сайтом.

8. Сайт очень трудно использовать.

9. Я уверенно себя чувствовал(а), используя этот сайт.

10. Мне пришлось многому научиться, прежде чем я смог(ла) работать с сайтом.

Просим оценить, насколько пользователи согласны с каждым из утверждений по шкале от 1 (совершенно не согласен) до 5 (полностью согласен).

SUS = (Σбаллов по всем вопросам - 10) ∗ 2,5

Чем выше итоговый балл, тем более высоко пользователи оценивают юзабилити продукта. Подробная интерпретация результатов SUS выглядит так:

• Балл < 50: пользователи считают продукт неудовлетворительным.

• Балл от 50 до 70: пользователи считают продукт приемлемым, но есть место для улучшений.

• Балл > 70: пользователи считают продукт хорошим.

P. S. Больше о работе с диджитал-продуктами в нашем телеграм-канале. Приходите :)

Запуск нового проекта: когда Time and Materials дороже Fixed Price, и на что лучше потратить эту разницу

Недавно мы сравнили модели Fixed Price и Time and Materials на примере типичного среднего проекта: прошлись по всем этапам и проследили, как меняется бюджет от пресейла до релиза.

В нашем примере проект по T&M вышел примерно на 5 миллионов дороже, чем Fixed Price проект. При этом проект по T&M получился более продуманным. Но мы считаем, что это не стоит таких сверхвложений.

По нашему мнению, лучше потратить разницу в 5 миллионов на постепенный запуск продукта — Soft Launch. Это когда мы тестируем первую версию проекта на ограниченной аудитории. Потом исправляем ошибки и только тогда выпускаем продукт для большей аудитории.

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

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

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

Полную версию этой статьи найдете тут. А об управлении проектами читайте в нашем телеграм-канале.

Чек-лист для самоконфликта. Как мы учим менеджеров прогнозировать

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

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

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

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

Главная задача — задать правильные вопросы, чтобы менеджер засомневался во всех возможных вариантах ответа, но нащупал границы и выплыл с точным прогнозом.

Со временем такие вопросы превращаются в чек-лист для самоконфликта. Вопросы могут отличаться, но их объединяет сомнение «Уверен ли я, что…».

В полной версии статьи еще больше примеров — читайте ее здесь.

P. S. Мы много пишем об управлении проектами в нашем тг-канале. Так что приходите, если интересно)

Изучаем анимацию переходов во Flutter

Пересказ большой статьи в маленьком посте.

Существует много типов анимации для Flutter-приложений. Среди них — Rive-анимация, Hero animations, Progressindicator и т. д. С их помощью можно создавать кастомную анимацию для любого вида работ с системой. Но наиболее базовое решение — библиотека Animations.

Она предоставляет стандартные анимации Material Design. Система движений Material Design состоит из четырех паттернов для перехода между компонентами. Вот они:

• Container Transform. Он предназначен для переходов между элементами интерфейса, включающими контейнер. Паттерн создает видимую связь между этими элементами.

• Shared Axis. Его используют для переходов между элементами пользовательского интерфейса, имеющими пространственную или навигационную связь. Паттерн использует общую трансформацию по осям X, Y или Z для усиления взаимосвязи между элементами.

• Fade Through. Его используют для переходов между элементами интерфейса, не имеющими тесной связи друг с другом.

• Fade. Он для элементов интерфейса, которые входят или выходят за границы экрана. Например, диалог, который появляется и исчезает из центра экрана.

В шаблонах Shared Axis и Fade Through также нужно использовать библиотеки для навигации. В нашем случае это go_router. В Container Transform и Fade навигацию можно не использовать.

Посмотреть, как работают анимации, можно в репозитории, подробности и примеры кода — в нашей статье, а про Flutter — в телеграм-канале.

3 простых способа оценить свою стоимость на рынке труда

Способ №1. Провести исследование рынка

Для этого создано много инструментов. Например, Хабр Калькулятор покажет, какая зарплата у людей с таким же опытом, как у вас. Еще каждые полгода Хабр публикует анализ зарплат IT-специалистов. Собранная там статистика может помочь.

Чтобы посмотреть средние зарплаты по другим странам, можно воспользоваться сайтом Glassdoor. Свой калькулятор зарплат есть и у HeadHunter. Там же можно узнать средние зарплаты по рынку просто посмотрев релевантные объявления.

Плюсы: бесплатно, быстро, точно.
Минусы: без учета нюансов.

Способ №2. Развивать нетворкинг

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

Плюсы: бесплатно.

Минусы: неточно, ненадежно.

Способ №3. Поговорить с карьерным консультантом

Такие специалисты постоянно мониторят рынок и анализируют зарплату. К тому же они могут оценить ваш уровень компетенций и стоимость, а еще составить карьерную стратегию. Пройти консультацию можно, например, через Careerspace или «Эйч».

Плюсы: с учетом всех нюансов, надежно.

Минусы: дорого, иногда долго.

За вакансиями в AGIMA следите в нашем телеграм-канале.

Продакт-менеджмент: что такое PMF и как его измерять

Product-Market Fit (PMF) помогает определить, насколько продукт соответствует потребностям рынка и пользователей. Если PMF достигнут — продукт начинает приносить прибыль. Но важно помнить, что определение PMF — не финальный результат, а постоянный процесс.

Существует несколько подходов к PMF.

1. Опрос PMF — правило 40%

Эффективный способ замерить (но PMF — не метрика!) соответствие продукта рынку. Может содержать разные вопросы, но обязательным будет: «Как бы вы себя чувствовали, если бы больше не могли использовать продукт?»

Варианты ответов:

а) сильно расстроюсь;

б) немного расстроюсь;

в) не расстроюсь;

г) уже не пользуюсь.

≥40% пользователей дали ответ А — PMF достигнут.

25–40% — есть шансы достичь PMF, но нужно что-то поменять. 

<25% — скорее всего, требуется кардинальный пересмотр вижена.

2. Соотношение LTV/CAC

Другой подход к определению PMF — использовать данные аналитики. Концепция проста: PMF достигнут, когда клиенты платят больше, чем мы тратим на привлечение новых. То есть пожизненная ценность клиента (LTV) больше, чем стоимость привлечения клиента (CAC). Для достижения PMF это соотношение должно быть ≥3.

При обоих подходах нельзя упускать ключевые моменты:

• продукт должен удовлетворять потребности пользователей;

• продукт должен иметь преимущества, которые отличают его от конкурентов;

• продукт должен быть простым и удобным.

Больше о работе с цифровым продуктом читайте в нашем телеграм-канале.

Разбираемся с yield во Flutter

Начинающие Flutter-разработчики не всегда понимают, для чего нужно ключевое слово yield в Dart. Оно используется в генераторах Stream для пошаговой передачи данных. Это полезно в BLoC для управления состояниями и событиями. 

Примеры использования yield в Dart:

1. Простой генератор:

Stream<int> countStream(int to) async* {
  for (int i = 1; i <= to; i++) {
    yield i; // Постепенно выдаёт числа от 1 до to
  }
}

Так мы можем создать поток, который поочередно выдает числа от 1 до указанного значения.

2. Использование в BLoC

class CounterBloc extends Bloc<CounterEvent, CounterState> {
  @override
  CounterState get initialState => CounterInitial();
  @override
  Stream<CounterState> mapEventToState(
    CounterEvent event,
  ) async* {
    if (event is Increment) {
      yield CounterLoading();
      // Представим, что здесь какая-то асинхронная логика
      yield CounterLoaded(newState);
    }
  }
}

Здесь yield используется для отправки различных состояний (например, загрузки и загруженного состояния) в ответ на события.

yield во Flutter — это мощный инструмент для создания асинхронных потоков данных и управления состояниями в BLoC. Он делает код более чистым, понятным и поддерживаемым. А если говорить совсем просто, то yield добавляет значение к выходу потока функции async*. Это как return, но он не завершает функцию.

Подписывайтесь на телеграм-канал руководителя нашего направления Flutter/iOS Саши Ворожищева, чтобы узнать про Flutter больше.

Что добавить в CI при настройке GitLab CI/CD на Flutter-проекте?

Вот два примера команд для Static-проверок от нашего Flutter-разработчика Саши:

1. dart-metrics-analyze
   
   Поможет нам проанализировать код, выявить ошибки стиля и проблемы, которые могут повлиять на качество кода и сложность его поддержки.

dart-metrics-analyze:
  stage: static
  interruptible: true
  before_script:
    - flutter pub get
  script:
    - flutter pub run dart_code_metrics:metrics analyze --fatal-style --fatal-performance --no-fatal-warnings --reporter=console lib
  tags:
    - ci

2. dart-metrics-check-unused-files
   
   С помощью этой задачи можно проверить, все ли файлы в коде действительно использованы. Лишние файлы могут усложнять код и увеличивать время его компиляции.

dart-metrics-check-unused-files:
  stage: static
  interruptible: true
  before_script:
    - flutter pub get
  script:
    - flutter pub run dart_code_metrics:metrics check-unused-files --fatal-unused --exclude="{lib/application/core/bloc/void_action_bloc.dart,lib/util/log.dart}" lib
  tags:
    - ci

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

Больше примеров и деталей найдете в нашей подробной инструкции по настройке GitLab CI/CD на Flutter-проекте.

P. S. А еще ждем вас в нашем телегам-канале про Flutter и не только.

Простая идея для канбан-доски, которая делает работу прозрачней

Пересказываем большую статью в маленьком посте.

Недавно мы заметили, что некоторые задачи на наших канбан-досках застревают на приемке у заказчиков. Например, задачу с нуля мы делаем 10 дней, а потом в колонке Client Acceptance она может лежать еще 20–30. Ситуация повторялась на разных проектах и явно была общей.

Мы быстро поняли, в чем дело. На стадии Client Acceptance команда получала замечания от заказчики. И пока они вносились, задача оставалась в этом же столбце. По правилам Канбан, двигать ее назад нельзя. Хотя, по сути, всё это время она проходила тот же путь, что и до этого — через To do, In progress и Validation.

Эта ситуация нас не устраивала. Из-за этого мы не могли грамотно расставить приоритеты. Например, одну задачу мы впервые показали заказчику, а другая уже на третьей итерации. Когда обе задачи в одном столбце — приоритет у них один. Хотя лучше доделать ту, в которой накоплено больше ценности.

Чтобы вывести задачи из слепой зоны, мы визуализировали процесс работы над замечаниями. Для этого добавили дополнительные свимлайны. Каждый из них повторял основной воркфлоу. Теперь задача возвращалась в To do, но в другом свимлайне.

Благодаря этому решению мы:

• упростили и оптимизировали работу;

• начали лучше контролировать работу отделов;

• сделали работу прозрачной для заказчика.

Подробнее о том, почему эта идея улучшила нам жизнь — в отдельной статье. А больше про управление проектами — в нашем телеграм-канале.

Сложности работы с GraphQL, или Почему не стоит его использовать повсеместно

1. Внедрение GraphQL — это сложно. Поэтому перед практическим использованием выделите достаточно времени и ресурсов для изучения концепции и структуры.

2. Когда вы реализуете REST API, можете закэшировать ответ по каждому эндпоинту. В GraphQL запросы динамические, содержат разный набор полей и связей:

query {
  user(id: 1) {
    id
    name
    posts {
      id
      title
      comments {
        id
        text
      }
    }
  }
}

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

3. А теперь представьте, что в запросе выше ещё больше вложенных запросов. По умолчанию GraphQL не ограничивает вас в глубине вложенности, что может вызвать шквал базовых запросов. Это сказывается на производительности сервера.

4. GraphQL не гарантирует атомарность выполнения нескольких мутаций:

mutation {
  createPost(title: "New Post", body: "Content") {
    id
    title
  }
  updateAuthor(id: 1, name: "New Name") {
    id
    name
  }
}

С одной стороны, это гибко и удобно, а с другой, — а что произойдет, если одна мутация пройдёт, а другая отвалится?

Поэтому не стоит жечь напалмом REST API и переписывать всё на новую технологию. GraphQL — удобный инструмент, но перед использованием важно понять, на каких проектах эта гибкость пригодится, а где будет лишней.

Больше об управлении разработкой — в нашем телегам-канале.