I hate overtime – Telegram
I hate overtime
866 subscribers
129 photos
4 videos
54 files
961 links
Some DevOps, SRE and IT development stuff
Download Telegram
Forwarded from Bang Bang Education
7 основных методов UX-исследований

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

Сортировка карточек

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

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

Ревью эксперта

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

Айтрекинг

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

Полевые исследования

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

Юзабилити тестирования

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

Дистанционное юзабилити тестирование

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

Создание персон

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

⚫️ Сегодня в 19:00 мы проводим бесплатный вебинар с руководителем команды экспертов по клиентскому опыту в трайбе Digital Business Platform, Cбербанк Алиной Ермаковой. Тема — «Удобство продуктов: как UX помогает делать востребованные сервисы». Регистрация → bangbangeducation.ru/webinars/uxresearch
Forwarded from Maxim Shalomovich
Классный вопрос на самом деле. С одной стороны есть "классика" с вьюпойнтами, достижениями Кратчена, SAD и всем остальным. С другой - есть Agile-команды и проекты с изменениями, эволюционная архитектура и т.д. Через недельку как раз тут - https://lanit-events-org.timepad.ru/event/920546/ - будем об этом говорить (попытаемся по крайней мере). Подключайтесь к онлайн конференции (на первый день очные места уже выбраны), приходите в остальные дни, приходите на круглый стол. Мнение сообщества и опыт реально интересны
Кстати, меня тут подогрели крутой презой про культуру разработки в Netflix(великом и ужасном):
Вот такое происходит. Ну что, пока, TeamCity и Bamboo?
Forwarded from DevOps Deflope News
Вчера Linux Foundation анонсировал Continuous Delivery Foundation, созданный для развития современных инструментов поставки.

В CDF уже захостились Jenkins, Jenkins X, Spinnaker, Tekton.

Основателях 20+ компаний, включая Netflix,Google,CloudBees,RedHat
http://amp.gs/4hRJ
Пока ничего нигде не происходит, затру телегу за проведение собесов(
последнее время очень часто приходилось рассказывать как я провожу тех. собеседования и по каким критериям отбираю кандидатов, так что опишу все тут и буду кидаться ссылками).

Во-первых, я не проверяю софт-скилз, ответственность, усидчивость и все вот это. Для этого, кмк, есть испытательный срок, на котором вылезет 80% косяков, а это и так максимум на который можно расчитывать. Тем не менее я задаю пару общих вопросов, что бы понять общую логику и мотивацию кандидата. Обычно это что-то типа: "что вы делаете для того что бы профессионально расти?(тут я жду, что чувак расскажет про книги, которые он прочитал, курсы, которые прослушал и т.д.)", "какое было ваше самое большое достижение на предыдущем месте работы?"(тупо для затравки), "а какой был самый большой факап?"(тоже вобщем-то для затравки, но так же для понимания того готов ли чувак отвечать за свои косяки. Для того что бы чувак расслабился я, обычно, рассказываю про какой-то из своих залетов), ну и самое главное: "а чему вы научились в результате этого горького опыта?"(надо понять что чувак как-то обрабатывает обратную связь, анализирует свою деятельность и т.п.). Так же, стандартно спрашиваю чем бы чувак на 100% не хотел заниматься на работе и почему(на этом вопросе из кандидата очень часто почему-то вылезает все говно). Вот вобщем-то и все общие вопросы.

Дальше по списку идет опыт работы. Честно говоря, мне кажется, что вот прям заострять внимание тут стоит только если собеседуете синиора-помидора или выше. Дело в том, что джуны и мидлы на работе "работают работу", особо не принимая каких-то решений приводящих к глобальным последствиям. Но прослушать рассказ чувака все же надо, как минимум ради того что бы узнать почему чувак свалил(тут, как не странно, тоже выливается много говна). Для синиоров на этом история не заканчивается, т.к. ретроспектива прошлого опыта -- это единственная возможность понять готов ли чувак принимать решения и нести за них ответственность. Для этого можно попросить рассказать про архитектуру(стек/процессы/что угодно) на последнем месте работы и начать задавать вопросы из серии "а почему так, а не вот так?". Абсолютно не приемлемый ответ тут: "ну это тех. дир(тим.лид/архитектор) решил", т.к. с такими лычками надо уже участвовать в принятии решений и уметь как-то отстаивать свое мнение.

Ну и, собственно, тех. интервью. Тут ваще все просто: надо просто определить минимум скилов для кандидата при котором вы готовы взять его на позицию. У меня это обычно:
+ для джуна -- возможность как-то закрывать тикета (разраб должен знать язык на котором разрабатывает, одмен должен уметь в туллинг как системный так и в IaaC. Причем уметь/знать -- это, конечно же, подразумевает, что уметь надо хорошо)
+ для мидла -- надо уже уметь решать задачи самостоятельно(для разраба нужно уметь в дизайн, понимать как работает его софт и т.д., одмен должен мочь собрать пайплайн, поднять тачки и базы, настроить сети, опираясь на требования/спецификации)
+ синиор, как уже было сказано, должен уметь принимать архитектурные решения. Тут, соответственно , надо зарамсить за архитектуру(софтварную для разраба и деплоймент для инфраструктурщика), понимать как работает система в целом, а не конкретные сервисы, иметь какое-то понимание о трейд-офах и т.д.

Кароч все достаточно просто. Вот и все, вот и все)
Forwarded from kamyshev.code
Исследуя GitHub

Некоторое время назад писал о процессе публикации npm-пакета.

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

Хотелось переложить максимум забот на компьютер, и избежать этой боли. На выходных сделал библиотеку @solid-soda/noscripts, которая содержит в себе все рутинные штуки. Линтер, преттир, генерация новых версий, все там.

Теперь любой проект начинается с установки этой библиотеки.

#автоматизация
Вот, кстати, библиотечка Discovery и Delivery практик https://openpracticelibrary.com/
Конечно, в значительной мере эта заметка - реклама продуктов LightStep. Тем не менее, микросервисная архитектура, действительно, может позволить управлять организационной структурой ИТ-подразделения https://lightstep.com/blog/the-only-good-reason-to-adopt-microservices/
​​Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions (2016)
Авторы: Грегор Хоп, Бобби Вульф

#design_patterns #book #english #advanced

Язык: английский.

Целевая аудитория: опытные разработчики.

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

В книге рассматриваются следующие темы:
стили интеграции;
системы обмена сообщениями;
каналы обмена сообщениями;
маршрутизация сообщений;
управление системой и многое другое.

Преимущества:
многочисленные примеры;
качественный материал по теме.

Недостатки:
не обнаружено.
Книги для программистов
​​Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions (2016) Авторы: Грегор Хоп, Бобби Вульф #design_patterns #book #english #advanced Язык: английский. Целевая аудитория: опытные разработчики. Для взаимодействия компонентов…
Книжка очень хорошая (рально маст-рид для тех у кого распределенные архитектуры), но название не соответствует содержанию. Вся книжка про мессаджинг, а про остальные способы интеграции(общая база, файлообмен, RPC) там буквально пара страниц <s>негатива</s>. Не, ну безусловно, мессаджинг должен быть дефолтным способом интеграции, но только им обойтись не получится, так что придется вооружаться еще какой-то макулатурой, что бы получить полную картину
Forwarded from CatOps
​​KeyDB - A Multithreaded Fork of Redis

John Sully disagrees with Salvatore Sanfilippo’s thoughts on multithreading, so he make own Redis, with multhithreading and enterprise features.

KeyDB have:
- 60% lower latency
- direct backup to AWS S3
- FLASH storage support

KeyDB designed with AWS in mind and has full compatibility with the Redis protocol, modules, and noscripts. This includes full support for transactions, and atomic execution of noscripts.

#database #aws
Forwarded from Библиотека программиста | программирование, кодинг, разработка
Монорепозиторий: 7 фактов, которые должен знать каждый

Монорепозиторий используют в Google, Facebook, Twitter. В чем его прелесть? Вот перечень основных плюсов и минусов монорепозиториев.

https://prglb.ru/4062u
Библиотека программиста | программирование, кодинг, разработка
Монорепозиторий: 7 фактов, которые должен знать каждый Монорепозиторий используют в Google, Facebook, Twitter. В чем его прелесть? Вот перечень основных плюсов и минусов монорепозиториев. https://prglb.ru/4062u
При всех этих хайп-воплях за монорепу и транк-бейзд мне резко вспоминается вот этот видос: https://youtu.be/W71BTkUbdqE где extremely pregnant тетя из гугла объясняет(несколько раз), что они юзают все это добро потому что у них есть специальный(Карл!) туллинг, написанный, специально(Карл!) под это дело! А у кого такого специального(Карл!) туллинга нет, то ни в коем случае лезть в это не надо