В статье я затрону важную тему — какие метрики должен знать и использовать продуктовый дизайнер. На примере Домклик мы посмотрим с какими метриками работает наш дизайн-отдел и ответим на следующие вопросы:
1) Какие метрики должен знать и использовать продуктовый дизайнер?
2) Почему это так важно и какие метрики стоит держать под рукой?
3) Изучим методы сбора и анализа полученных данных.
* бонусом разберём несколько примеров.
Придя на работу в Домклик ведущим дизайнером, у меня в подчинении оказались 12 продуктовых дизайнеров. Каждый из них работал на своей Kanban-доске в Jira, а некоторые — на общих досках с разработчиками. Также каждый из дизайнеров ежедневно заканчивал делать макеты по 1-2 продуктовым задачам и присылал их мне на проверку и согласование лично в Telegram. Думаю, понятно, что через неделю работы в таком режиме я начал зашиваться, и мой мессенджер стал выглядеть как бермудский треугольник, в котором терялись сообщения от коллег, родителей, семьи, начальника. Я целый день только и делал, что разгребал сообщения, отвечал ребятам-дизайнерам на сообщения по задачам и проверял их работы. Нужно было что-то менять, и я первым делом составил список процессных проблем, которые хотел решить.
Здравствуйте! Меня зовут Игорь, и я руковожу несколькими направлениями в команде DevOps-инженеров, включая направление мониторинга.
Сегодня я хочу рассказать вам о нашем уникальном решении для Zabbix. Это решение позволяет быстро уведомлять о найденных уязвимостях, формировать список этих уязвимостей и предоставлять дополнительную информацию о них.
Возьмите вкусняшек, чайку и присаживайтесь поудобнее.
Сдача макетов — важный и ответственный этап для дизайнера, требующий внимания к деталям и тщательной проверки. В этой статье я попытался собрать основные пункты, которые облегчат процесс проверки и повысят качество ваших работ.
Материал разработан как для опытных продуктовых дизайнеров, так и для начинающих специалистов, и носит рекомендательный характер.
SOLID-ная статья о принципах SOLID, которую вы можете предложить тем, кто хочет понять эти принципы в контексте языка Go. Или прочитать самостоятельно, если это интересно и вам.
И да, как сказал бы волк из небезызвестного мультика: «SOLID? Шо, опять?»
Мало кто пишет, чем занимается команда дизайн-системы. Обычно пишут, как сделать компонент, как оформить или передать его в разработку. Эта же статья уникальна в своем роде — такой материал вы редко встретите в русскоязычном интернете.
Будь эффективным — используй «туллинг»!
В этой статье я хочу поделиться с вами своим опытом и рассказать о наиболее полезных инструментах, которые я использую в своей повседневной работе. Мы рассмотрим как широко известные, так и менее популярные, но не менее ценные утилиты, которые помогут вам стать более эффективным Android‑разработчиком.
Статические анализаторы уже давно являются неотъемлемой частью разработки проектов не только на Android. Они позволяют выявлять ошибки, несоответствия стандартам code style, производительности или безопасности, обозначать какие-то узкие места, сокращать code review и т. д. Android Studio «из коробки» содержит огромное количество всевозможных проверок, но, как правило, этого недостаточно, всегда есть какие-то неучтённые проблемы, внутренние правила компании или команды разработки. Кратко расскажем про Lint, как начинали делать свои правила, с какими задачами сталкивались на первых этапах и как решали. Это поможет вам впервые погрузиться в тему, так как интернет весьма скуден на статьи по ней.
В последнее время внутри дизайн-сообщества часто поднимается тема «эмоционального дизайна». Статей и материалов достаточно, и каждый затрагивает какой‑то определённый аспект этой темы. Я попытался собрать все знания, включая свои наработки, чтобы ответить на вопрос, а существуют ли критерии оценки эмоций от дизайна, и бывает ли дизайн эмоциональным в принципе.
В последнее время всё чаще и чаще натыкаюсь на термин data contract. И чтобы не отставать от трендов на рынке data engineering, решил изучить эту тему и рассмотреть тенденции. Постараемся понять, с чем его кушать и стоит ли кушать вовсе.
Существует популярный подход к покрытию метриками Celery: он заключается в запуске некоторого процесса, который слушает события из специальной очереди, на основе этих событий обновляются объекты метрик, а фоновый поток сервера отдаёт собранные метрики скраперу. В этой статье подробно разберём события, их жизненный цикл, откуда и как их принимать. Также поговорим про механизм удалённого управления (remote control), какие у него есть возможности и как им пользоваться. Обсудим существующие решения, чем они отличаются, и почему вам, возможно, будет выгодно сделать своё.
При разработке больших web-проектов нам часто приходится взаимодействовать с API сторонних или внутренних микросервисов. Когда количество таких взаимодействий растёт, настройки вызовов к другому API и подробности самих вызовов кратно множатся и могут растекаться по проекту.
В Домклике у нас микросервисная архитектура, и каждому сервису приходится взаимодействовать с десятком других. Чтобы межсервисное взаимодействие было предсказуемым, надёжным, удобным и отслеживаемым, мы следуем ряду практик при разработке, и в этой статье я расскажу вам о них.
Я покажу свой способ сборки компонента List Cell, объясню, почему считаю его гибким, а также приложу ссылку на Figma. Я решил рассказать об этом потому, что не нашёл подходящих материалов, как собрать свой List Cell.
Привет, меня зовут Артём Говердовский, и я дизайн-директор в Сбер Домклик. В моëм подчинении 49 дизайнеров, среди которых 6 лидов. Хочу рассказать, как у нас получилось переформатировать дизайн-отдел, распределить зоны ответственности, настроить процессы, справиться с легаси и полностью синхронизироваться по всем проектам за 9 месяцев работы.
Существует много курсов программирования и повышения IT-квалификации, но ни на одном из них не учат системно искать и исправлять ошибки. В реальных крупных проектах до 30% времени может уходить не на написание нового кода и фич, а на поиск первопричин неисправностей и их устранения. Именно недочёты и ошибки будут мешать вашему клиенту составить положительное впечатление о продукте, а в некоторых случаях они полностью блокируют процесс. Кроме того, инженер, который только пишет новый код и не решает ошибки, не получает архитектурный опыт и не расширяет кругозор, что приводит к появлению новых недочётов в проектах. Я опишу наш инструментарий для исправления ошибок в веб-приложениях и поделюсь опытом.
Всем привет! Меня зовут Егор Молчанов, я разработчик в команде CRM для менеджеров ипотечного кредитования в компании Домклик. Хочу поделиться своим опытом создания VR‑тура с помощью фреймворка A‑Frame и библиотеки React. Для этого написал свой небольшой pet‑проект, который мы сейчас разберём.
Под конец прошлого года, по ряду причин, ESLint отказались от дальнейшей поддержки и развития стилистических правил. А тема, как по мне, несправедливо осталась в тени. Давайте разберемся, почему так произошло и какие изменения нас ждут на поприще статического анализа и форматирования кода.
Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. Недавно стал общедоступен новый линтер «Oxlint», основанный на языке программирования Rust, и многие эксперты высоко оценили его. Какие преимущества Oxlint предоставляет по сравнению со своим предшественником ESLint?
На данный момент у нас используются три самых популярных менеджера пакетов (Npm, Yarn и Pnpm). И всё бы ничего, но разные команды начали периодически обращаться с проблемой несоответствия типов Typescript из наших транзитивных зависимостей. Выяснилось что это проблема Npm и Yarn, но как же её решать?
На ум сразу приходит самое очевидное решение: следить за версиями всех зависимостей в своих проектах и вовремя обновлять. К этому, естественно, необходимо стремиться всегда, но мы понимаем, на практике что это крайне сложно, а в legacy-проектах или в проектах, у которых нет постоянной поддержки и вовсе нереально. Следующим вариантом созрел Pnpm, тем более что в наших монорепах он себя уже продолжительное время отлично показывал. Я решил испытать его на действующих клиентских приложениях.
Друзья, всем привет! Идемпотентность в проектировании API — не просто формальность. Это свойство, часто рассматриваемое как способ получения одинакового ответа на повторяющийся запрос, на самом деле означает гораздо больше...
