Как стать автором
Обновить
132.34
AGIMA
Крупнейший интегратор digital-решений
Сначала показывать

Разбираемся с 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 больше.

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии0

Что добавить в 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
  1. 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 и не только.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

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

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

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

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

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

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

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

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

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

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

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

Теги:
Всего голосов 4: ↑4 и ↓0+4
Комментарии0

Сложности работы с 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 — удобный инструмент, но перед использованием важно понять, на каких проектах эта гибкость пригодится, а где будет лишней.

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

Теги:
Всего голосов 6: ↑6 и ↓0+6
Комментарии1

PI-планирование, или Почему нам стало легче дышать

Один из наших заказчиков — известный бренд, который развивают Ecom-направление. Мы работаем с ними уже пять лет, но начиналось всё так себе. Первое время мы не могли найти общий язык, спорили из-за мелочей. Всё как в басне «Лебедь, рак и щука».

Но затем нашли лекарство — PI-планирование. Рассказываем, как его проводим мы.

PI-планирование — это регулярная встреча всех команд проекта и его стейкхолдеров. Она помогает держать фокус на общей цели и синхронизировать действия нескольких команд сразу.

PI-планирование идет от бэклога. То есть на встрече мы не пополняем доску задачами, а все вместе распределяем их по двухнедельным таймбоксам. У нас встречи проходят онлайн.

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

В итоге мы стали понимать KPI стейкхолдеров и глобальные задачи бизнеса. Вот главные плюсы PI:

  1. Мы обеспечиваем команде равномерную нагрузку.

  2. Мы делим ответственность за проект с заказчиком.

  3. Мы лучше распределяем ресурсы.

PI-планирование точно стоит внедрить тем,

✔️ кто строит команду на аутсорсе;

✔️ у кого над продуктом работает несколько команд.

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

Теги:
Всего голосов 6: ↑6 и ↓0+6
Комментарии0

Истории

Что мы делаем, когда задача приходит на разработку без планирования

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

После начала нового цикла может прилететь срочная задача, которую заказчик не успел формализовать к планированию.

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

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

Если коротко, то выбираем решение с еmail-рассылкой, потому что многие пользуются VPN и по IP мы ничего выяснить не можем. Бэк генерирует уникальную ссылку и промокод, получить его можно кликнув по своему городу в письме.

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

Рассылаем акцию в понедельник, а в во вторник собираем статистику. Вот как это выглядит на схеме:

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

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии0

Чек-лист: как понять, что компании нужен карьерный сайт

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

Ребята из нашего PHP-направления разработали универсальный бэкенд для карьерных сайтов на Laravel. Наша «коробка» — это пять ключевых фич, они покрывают 90% потребностей рекрутеров. Остальное — кастомные решения. Вот эти фичи:

  • интеграция с Хантфлоу;

  • админка с функционалом под создание лендингов;

  • интеграция с поисковой системой Elasticsearch с синонимичным поиском;

  • факультативный блок с новостями;

  • рендеринг картинок для шеринга.

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

✔️ вы много и интенсивно нанимаете, в постоянной работе у вас от 100–150 вакансий;

✔️ вам не хватает возможностей HH и подобных площадок, чтобы показать преимущества компании;

✔️ вам нужна подробная аналитика по каждой позиции.

В статьях по теме иногда предлагают еще два пункта, но они факультативные:

✔️ вам сложно закрывать отдельные позиции, их нужно активнее продвигать;

✔️ у вас сложные тестовые задания, их условия нужно подробно описывать.

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

Больше о «коробке», карьерных сайтах и подборе IT-специалистов — в нашем блоге.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии1

Как работать со старожилами компании, которые стали неэффективными. Инструкция для тимлидов

Если компания на рынке хотя бы 10–15 лет, в ней точно есть сотрудники-старожилы. Когда-то они решали нерешаемые задачи и были незаменимы. Но технологии и процессы шагнули вперед, а они нет. Ниже советы, как вернуть их в строй.

1. Разговаривать.

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

2. Учить новому.

Когда человек годами на одном проекте, он забывает, как работать над другими. Оцените его остаточные знания. Может, просто отправить его на курсы?

3. Строить план развития.

Можно внести в KPI, какие технологии ему освоить. Причем новые знания нужно применять на практике. Поэтому подкидывайте ему интересные задачи, тренинги.

4. Мотивировать.

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

5. Следить и поддерживать.

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

6. Принимать решения.

Если все усилия не помогли, придется задуматься о расставании. Не все готовы меняться, это нормально. Помнить об этом варианте нужно с самого начала.

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

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

Как заказчик пришел к нам за новой фичей, а мы его отговорили

Это пересказ статьи из нашего блога.

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

Чтобы разобраться, мы предложили провести UX-аудит.

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

Для UX-аудита мы совместили два метода:

  1. Эвристический анализ — это метод, при котором UX-эксперт ходит по сайту и анализирует каждый шаг и сценарий.

  2. Когнитивное прохождение — это метод, при котором исследователь прописывает все возможные сценарии и анализирует их.

Наша догадка подтвердилась: внедрять личный кабинет было рано, сначала нужно было поменять структуру. Для этого мы использовали карточную сортировку. Эта методология подсказывает, как упростить навигацию, логику разделов и т. п. Например, она помогла нам организовать корпоративную базу знаний.

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

Все иллюстрации и подробности — в нашей статье. А больше про аналитику — у нас в телеграме.

Теги:
Всего голосов 2: ↑0 и ↓2-2
Комментарии0

Rive для Flutter-приложений: что нужно знать

Привет! Я Никита Грибков, Flutter-разработчик в AGIMA. Сегодня расскажу вам про возможности Rive. Это фреймворк, который использует векторную графику для создания анимации во Flutter-приложениях. Я использовал его, чтобы сделать кнопки для Bottom Bar в своем пет-проекте. 

Элементы для анимации можно создавать в программных продуктах типа SVG или Adobe Illustrator. У меня не было опыта работы с векторной графикой, поэтому я использовал встроенный в Rive UI-интерфейс. Еще в Rive есть раздел Community. Там авторы выкладывают бесплатные анимации.

Вообще в Rive несколько слоев:

  • статический слой — это слой, который отображает элемент в неподвижном состоянии;

  • анимационный слой — это временная линия, на которой можно задавать ключевые кадры для изменения формы, цвета и размера элементов;

  • State Machine — это часть фреймворка Rive, которая позволяет создавать сложные анимации. Он использует конечный автомат (FSM) для определения состояний и переходов между ними.

Чтобы внедрить Rive в приложение, нужно всего 2–3 строки кода. Хотя это может зависеть от сложности анимации. Но на первый взгляд, код здесь компактный и легко поддерживаемый.

Вот что получилось в итоге:

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

P. S. А еще у моего коллеги Саши Ворожищева есть канал про Flutter. Приходите читать.

Теги:
Всего голосов 5: ↑5 и ↓0+5
Комментарии1

Мы внедрили OKR. Как? Зачем? Что теперь?

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

В прошлом году мы внедрили новую систему целеполагания — OKR. Ее используют гиганты вроде Google и Uber. И мы тоже решили попробовать. Главная причина: компания выросла, и нам нужно было подключить больше людей к стратегическим задачам.

А суть системы OKR как раз в том, что цели ставятся не сверху, а снизу. Так мы рассчитывали увеличить вовлеченность сотрудников в развитие компании. То есть буквально: чтобы все понимали, в какую сторону едет наша машина.

OKR — это не KPI. Главные отличия:

  • OKR трудно достижимы, они амбициознее и больше;

  • OKR на влияют на финансовую мотивацию;

  • OKR — это коллективная ответственность.

Новую систему мы внедряли методом проб и ошибок. Но начали с пирамиды метрик. В качестве North Star Metric взяли оборот, декомпозировали его и получили набор метрик низкого уровня.

Затем мы провели ретроспективу по итогам 2022 года, составили список побед и поражений. Обращали внимание на те, которые больше влияли на доход. Так мы нашли идеи, как сделать, чтобы этот год был лучше прошлого. Они-то и стали нашими OKR.

Чтобы их контролировать, мы:

  • Внедрили регулярные встречи раз в неделю.

  • После каждой встречи делаем мини-отчёт для сотрудников.

  • Назначили ментора по каждому OKR.

Что в итоге? Эксперимент продолжается. Мы пару раз профакапились, но смогли привлечь больше людей к стратегическим задачам. Достижимость OKR пока составляет 62%.

Все подробности о наших ошибках и открытиях здесь.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0
12 ...
7

Информация

Сайт
www.agima.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия
Представитель
Кристина Ляпцева