Обновить
25
0.6
Крупнейший интегратор digital‑решений@editor_agima

Пользователь

Отправить сообщение

3 нескучных приложения для бега

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

Relive

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

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

«Бег» от VK

Сервис «Бег» от VK синхронизируется с данными о тренировках с мобильных гаджетов и публикует их в приложении «ВКонтакте».

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

Zombies, Run!

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

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

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

P. S. А полезные для бега гаджеты мы рассматриваем в отдельной статье — сохраняйте :)

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

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

NoSQL — нереляционные БД, у них нет жесткой структуры. Скажем, у нас есть класс — пользователи. У каждого из них есть ID, имя, фамилия и проч. Эти данные помещаются в отдельный файл (а не в таблицу), и взаимодействие происходит только с этим файлом. Вы уже не можете забрать какое-то одно поле и работаете только с этим классом.

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

  • Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

  • Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

  • Если вы делаете энтерпрайз, лучше выбрать SQL. Представим, что в каком-то крупном маркетплейсе 10 тысяч человек оплатили покупки, но не получили товары, потому что транзакция данных прошла некорректно. Цена ошибки тут слишком высока — поэтому SQL.

Больше подробностей — в нашем блоге.

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

Docker Hub ушел из России. Чем это грозит?

Сегодня Docker Hub перестал работать для российских пользователей. Вместо репозитория открывается сообщение о блокировке IP-адресов в нескольких регионах мира, в том числе в Крыму. Однако сайт недоступен для всех россиян. Head of DevOps в AGIMA Дамир Грачев объясняет, почему это стало головной болью для большинства IT-компаний.

Стресс сегодня пережили многие, потому что тема микросервисной архитектуры стала модной в последние годы и Docker Hub был популярен. Из-за его отключения, по сути, упала инфраструктура многих проектов, остановился процесс выпуска релизов. Ломается сборка докеров, пайплайны и т. д. Могут даже ломаться кластеры Kubernetes, если в них ссылка на Docker Hub без зеркала.

Эта ситуация приводит к производственным сбоям. Все отвлекаются на решение этой проблемы. А если говорить глобально, то у каких-то компаний могут возникнуть проблемы с безопасностью. Сегодня мы увидели кучу странных зеркал на Docker Hub, которым сложно доверять. При их использовании произойти может что угодно — вплоть до повторении истории со СДЭКом.

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

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

Плюсы и минусы GetX и BLoC

Сравнение архитектурных подходов GetX и BloC
Сравнение архитектурных подходов GetX и BloC
  1. Простота в использовании.

    У GetX более низкий порог входа, он проще в освоении, чем BLoC. Он предоставляет простой и понятный API для управления состоянием, маршрутизации и управления зависимостями.

  2. Масштабируемость.

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

  3. Тестирование.

    В BLoC есть мощные средства для тестирования потоков событий и состояний, например bloc_test.

  4. Возможности.

    GetX предоставляет широкий спектр возможностей для маршрутизации и управления состоянием и зависимостями.

Что же выбрать?

Зависит от конкретных требований проекта и ваших предпочтений. Если приложение небольшое и простое, то GetX может быть более подходящим решением. Он предоставляет понятный API для работы, с ним можно писать меньше кода, что существенно экономит время.

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

Это часть статьи Flutter-разработчика Айдара Мавлетбаева — полную версию с кодом ищите тут.

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

Стили лидерства: как их использовать в работе

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

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

Подходит для кризисных ситуаций.

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

Подходит для задач, связанных с отказоустойчивостью систем. 

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

Подходит для творческих задач.

Демократ. Если либерал имеет свою цель и доносит ее до команды, то демократ формирует цель вместе с командой. Он делегирует ответственность, ему не важны детали выполнения задачи, ему важен конечный результат.

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

Узнать больше о самих стилях и о том, как их комбинировать, можно в отдельной статье.

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

Рекомендации врача: как минимизировать риски от сидячего образа жизни

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

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

1. На всё тело. Достаточно вспомнить разминку с уроков физкультуры и сделать что-то подобное: пройтись, сделайте наклоны, повороты головы и корпуса, повисеть на турнике.

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

3. На икры. Добавьте к разминке стояние на носочках, так вы защититесь от варикоза. Просто встаньте на носки и снова опуститесь на стопу несколько раз. Подъемы можно разнообразить: подниматься на носки, стоя в приседе или в наклоне.

4. На глаза. Медленно поморгайте 10–15 раз, зажмурьтесь, посмотрите в окно на предметы на разном расстоянии, «порисуйте» глазами круги, стрелки или простые картины, посмотрите стереокартинки.

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

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

Три совета продакт-менеджерам

1. Полезные инструменты, которые должны быть под рукой.

Продуктовые дашборды удобно строить в Tableau, а технические метрики отслеживать в Grafana. Еще могут пригодиться Amplitude для аналитики, Miro для майндмеппинга и Kaiten для управления работой продуктовой команды.

Ну и Excel/SQL — без них никуда.

2. Топ ошибок при разработке продуктовой стратегии.

1. Не продумать форс-мажор и план Б.
2. Строить стратегию, оторванную от практики, т. е. без метрик успеха, Roadmap и декомпозиции на проекты.
3. Планировать отдельно от разработки.
4. Считать только оптимистичный/обычный прогноз.
5. Закладывать риски менее 20%.

3. Как не поддаться панике, если стратегия не работает.

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

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

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

Это пересказ интервью с продактами из «Зоозавра», VK, World Class и AGIMA. Полная версия тут.

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

Резюме разработчика: на что обратить внимание

1. Одно резюме — одна позиция.

Иногда кандидаты хотят отразить в резюме все свои навыки. Поэтому в заголовках пытаются уместить всё: PHP-разработчик, Python-разработчик, QA-инженер и т. д. Но это только путает. Чем ближе заголовок резюме к названию вакансии, тем лучше.

2. Опыт интереснее всего.

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

3. Важничать — плохо.

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

4. Резюме должно быть читаемым.

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

5. Постоянство — плюс.

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

А еще всегда можно воспользоваться методом бутерброда. Удачи в поисках!

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

Готовьте кроссовки — RUNIT 2024 уже скоро!

RUNIT — самый большой ежегодный фестиваль спорта и IT в России. Он пройдет 7 июля в Москве в парке «Коломенское».

Кто будет?

В этом году на забеге соберутся рекордные 4000 участников — это разработчики, тестировщики, дизайнеры, менеджеры и все причастные к Digital-индустрии. А поддержать бегунов придут еще как минимум 2000 — их родные, друзья и коллеги.

Что будет?

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

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

Где и когда?

Открытие фестиваля
7 июля в 8:00. На целый день займем территорию музея-заповедника «Коломенское» в Москве. Это огромная зеленая зона с прекрасными видами на Москву-реку.

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

Билеты еще можно приобрести на официальном сайте. А самые свежие новости фестиваля — в телеграм-канале.

Ждем вас на старте!


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

Как развивать эмпатию

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

1. Анализировать конфликты.

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

2. Следить за своими эмоциями.

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

3. Активно слушать.

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

4. Получать обратную связь.

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

5. Читать книги.

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

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

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

Еще раз о дизайн-системах

Недавно у нас вышел кейс о работе над дизайн-системой для холдинга «Финам». Сегодня решили рассказать подробнее, что это такое и когда она может быть полезна.

Из чего состоит дизайн-система?

Дизайнеры создают UI Kit (набор готовых дизайн-решений) Разработчики переводят UI Kit в код → Код помещают в репозитории

UI Kit и репозиторий связаны с помощью токенов. Это единицы информации, которые хранят в себе константы: например цвет, радиус скругления кнопки, параметры шрифта и т. д. Если поменять значение токена в Фигме, оно попадает в репозиторий и затем автоматически синхронизируется с сайтом.

Когда и кому нужна дизайн-система

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

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

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

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

Однако есть и ложка дегтя

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

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

P. S. Го к нам в канал о дизайне :)

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

Как часто стоит менять работу

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

Раз в год и чаще

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

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

Минусы: человек не успевает погрузиться в проекты и пополнить портфолио, а еще кажется неуживчивым.

Раз в 2–3 года

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

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

Минусы: корпорации всё же ждут от кандидата большей стабильности, особенно от руководителей, а российским компаниям и вовсе нравится шаг в 3–5 лет.

Раз в 5–10 лет

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

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

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

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

5 главных трендов среди мобильных приложений в 2024 году


Приложения здоровья (mHealth)

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

E-commerce

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

Видео- и фоторедакторы

Здесь основной потребитель — поколение Z с его увлечением медиаконтентом. Смартфоны и мобильные приложения уже сейчас предлагают супервозможности для создания контента от идеи до публикации. А применение ИИ здесь создает невероятные перспективы — только взгляните на современную обработку видео и фото, генерацию голоса и субтитров, создание фильтров и анимаций. 

Финтех

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

Искусственный интеллект

ИИ так или иначе влияет на все вышеперечисленные отрасли. Но самым востребованным направлением здесь по-прежнему остается машинное обучение.

P. S. В полной версии этой статьи найдете еще больше деталей и аналитики по рынку мобильных приложений.

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

Как не выгорать, если иногда приходится перерабатывать

Недавно руководитель нашего направления PHP Саша Шутай написал большую статью о том, как совмещать личную жизнь и работу в IT. Там он рассказывает про классные техники и инструменты, которые помогают контролировать личное время и не перерабатывать, потому что переработки — зло.

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

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

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

?‍♂️ Занимайтесь спортом и хорошо высыпайтесь. Тут комментарии излишни. Сон восстанавливает энергию, а физическая активность — пополняет ее запасы. Отвлечетесь от работы, а заодно и здоровье поправите.

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

Другие способы не выгореть дотла в IT — в нашем блоге.

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

12 техник управления временем и задачами, помимо «Метода помидора»

Часть вторая

Правило 3-2-1. Каждый день вы фокусируетесь на трех основных задачах, двух дополнительных и одной по саморазвитию или личному росту. Помогает сосредоточиться на ключевых целях и приоритетах.

Reverse Planning. Сперва определяем желаемый результат и план шагов по его достижению. Затем каждый этап разбиваем на мелкие задачи и временные рамки. Получается ясный план действий с таймлайном.

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

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

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

Правило 90/90/1. Метод предполагает, что вы посвящаете первые 90 минут каждого утра в течение 90 дней на работу над самым важным проектом или задачей. Это помогает создать привычку приоритизации важных задач и эффективно расходовать силы.

Часть первая — по ссылке.

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

12 техник управления временем и задачами, помимо «Метода помидора»

Часть первая

Техника GTD. Эта система поможет организовать все ваши задачи и освободить ум от стресса и беспокойства о них. Принцип работы с задачами по GTD в пяти шагах: сбор, обработка, организация, обзор, действие.

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

Eat That Frog. Если начать день с выполнения самой неприятной задачи — буквально «съесть эту лягушку», — то остальные задачи покажутся легкими по сравнению с ней. Помогает избежать прокрастинации и повышает продуктивность.

Time Blocking. Этот метод заключается в разделении рабочего дня на временные блоки под конкретные задачи. Например, вы можете зарезервировать отдельные отрезки для работы над проектом, ответов на письма, звонков и т. д. Это помогает создать структуру и фокусироваться на конкретных задачах.

Zero-Based Calendar. Этот метод предполагает, что вы планируете каждый час рабочего дня заранее, не оставляя пустых слотов. Так не остается места для пустой траты времени и простоев.

2-Minute Rule. Этот метод предложен в книге Getting Things Done. Он гласит, что если задача занимает менее двух минут, ее следует выполнить немедленно, а не откладывать на потом. Это помогает избежать скопления небольших задач и повышает производительность.

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

Почему FilamentPHP — это хорошее решение для создания CMS

FilamentPHP — набор Fullstack-компонентов для Laravel. Последнее время мы в AGIMA часто используем его для построения админок. И вот почему:

1. Он красивый

Особенно в сравнении с Bootstrap. Filament же использует компоненты, стилизованные с помощью Tailwind CSS: 

Кстати, живую демку можно посмотреть и потрогать по этой ссылке.

Живую демку можно посмотреть и потрогать по этой ссылке.

2. Он доступный

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

А здесь найдете пример кода для создания формы авторизации.

3. Использует стек TALL (TailwindCSS, AlpineJS, Laravel, Livewire)

Livewire позволяет создавать приложение динамическим. Не нужно писать тонны кода на JQuery, как этого требует тот же Voyager. И, коли уж это Laravel, нам всегда доступны все его возможности.

4. Есть библиотека плагинов

И они закрыли уже почти все насущные проблемы.

Но и минусы у этого решения тоже есть:

  • Стек TALL можно отнести и к минусам тоже, потому что Livewire иногда кажется достаточно сомнительной затеей.

  • Filament достаточно прожорливый и требует OPCache и кеширования всего, что можно. И с включенным laravel-debugbar всё начинает тормозить.

  • Часть плагинов платные.

  • Код форм порой бывает достаточно… монструозным. Но это решается грамотным переиспользованием кода и разнесением его по разным местам.

Это краткий пересказ статьи Егора Черненка, PHP-разработчика AGIMA — полную версию читайте тут.

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

Наш опыт внедрения компонентной разработки

Компонентная разработка подразумевает деление мобильного приложения на отдельные компоненты (фичи). За каждый из них отвечает конкретный разработчик — Feature-оунер. Часть времени он посвящает задачам компонента, а часть — технической документации (Roadmap). Feature-оунер также контролирует работу остальных разработчиков, прикрепленных к фиче.

Мы решили перейти на новую методологию на текущем проекте по двум причинам:

  1. У тимлида на проекте было мало времени, его нужно было разгрузить.

  2. Проект смело можно назвать супераппом, он большой. И чтобы новый разработчик полноценно въехал в работу, обычно уходило 3–4 недели. Нам нужно было этот процесс ускорить.

Вот как мы распределили роли:

Методология подходит для больших команд — от 6 разработчиков. Идеально, если часть команды — это стажеры или джуниор-разработчики. В этом случае на позиции Feature-оунеров подходят миддлы, а в их команды можно добавлять стажеров или джунов.
Методология подходит для больших команд — от 6 разработчиков. Идеально, если часть команды — это стажеры или джуниор-разработчики. В этом случае на позиции Feature-оунеров подходят миддлы, а в их команды можно добавлять стажеров или джунов.

И вот что нам это дало:

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

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

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

Это короткая версия статьи о компонентной разработке от нашего тимлида Саши Омельяненко — весь текст читайте тут.

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

О школе Баухаус в цитатах дизайнеров

Наш арт-директор Федор Ноздрин и еще семь дизайнеров из известных студий рассказали порталу DSGNRS, как художественная школа Баухаус повлияла на них и на всё дизайн-сообщество. Делимся некоторыми цитатами из материала.

Источник

Федор Ноздрин, AGIMA:

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

Эмиль Исхаков, ONY:

«Баухаус объединил архитектурное, скульптурное и художественное мышление в мультидисциплинарной философии. Мы расширили это мультидисциплинарным подходом, включив типографику, CGI, генеративный, саунд- и диджитал-дизайн. Таким образом, мы являемся в некотором роде продолжателями Баухауса, создавая новые опыты для брендов через эксперименты с разнообразными медиумами и пробуя новые выразительные средства».

Павел Конюков, Nimax Brands:

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

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

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

О дуализме качественных и количественных исследований в UX

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

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

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

Об этом можно почитать у Джеффа Соро, известного аналитика: «Вам не нужно думать об этом как о ситуации или-или. Всегда можно использовать микс методов».

Он предлагает 3 различных дизайна исследований, при которых можно комбинировать методологии:

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

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

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

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

P. S. Это часть статьи Кати Патрикеевой о мифах в UX — полную версию читайте тут.

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

Информация

В рейтинге
2 127-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность