e-legion

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

2022-02-09T10:38:38.440Z

Всем привет! Меня зовут Настя, я аналитик в e-legion. Мы разрабатываем цифровые продукты на заказ, в том числе мобильные приложения, например, Мой Tele2, Альфа-Инвестиции, Пятерочка, My JetKid, Глобус и другие.

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

Процесс анализа на проекте

Сейчас практически на каждом проекте мы используем гибкие методологии. Рано или поздно команды приходят к Dual-Track Agile, когда спринты разделены на Discovery и Delivery. Аналитики и дизайнеры (консультируясь с разработчиками, конечно) в спринте Discovery готовят беклог для Delivery спринта. Т.е. к разработчикам и тестировщикам попадают описанные и спроектированные фичи.

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

Общий процесс анализа такой:

Определение потребности:

выявление бизнес-целей, бизнес-требований;
определение ограничений, правил;
выявление проблемы.

Определение решения.
Проектирование:

формирование пользовательских сценариев;
системное моделирование, разработка требований;
архитектура решения.

Документирование.
Управление требованиями.

Discovery track

В Discovery спринте аналитики тесно взаимодействуют с дизайнерами-проектировщиками, потому что в мобильных приложениях важен UX/UI. В процессе работы мы используем основы дизайн-мышления (методика, ориентированная на пользовательский опыт).

Мы выделили варианты взаимодействия аналитика и дизайнера:

1 вариант: аналитик -> дизайнер.
2 вариант: дизайнер -> аналитик.
3 вариант: дизайнер + аналитик.
4 вариант: дизайнер.
5 вариант: аналитик.

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

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

Ограничение при анализе

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

Потеря сигнала

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

РЕКОМЕНДАЦИЯ

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

Фрагментация

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

На одном из проектов в 2016 году мы разрабатывали авторизацию по отпечатку пальцев. FingerPrint появился в 6-й версии Android. Но были устройства с версией ОС ниже, где не поддерживался FingerPrint операционкой, однако сканер отпечатка был на устройстве. Поэтому мы придумывали обходные пути, писали свою библиотеку.

РЕКОМЕНДАЦИЯ

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

Обновление сборок

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

РЕКОМЕНДАЦИЯ

Можно предусматривать hard и soft update для управления обновлениями.

Возможности устройств

Зачастую мобильные приложения требуют взаимодействия через Bluetooth (носимая электроника, фитнес-девайсы), NFC (сканирование, оплата), геолокацию (карты), камеру и тд.

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

РЕКОМЕНДАЦИЯ

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

Особенности платформ

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

Особенности не всегда означают ограничения, а дают дополнительные возможности для бизнеса:

Apple Pay, GPay — упрощение пользовательского сценария оплаты.
Touch/Face ID, FingerPrint — упрощение пользовательского сценария авторизации или дополнительный фактор безопасности.
Apple Wallet — в программах лояльности сохранение промокода, билетов, карточек.
Deeplinking — тап на пуш или на ссылку из письма открывает конкретный экран.

Оптимизация работы

Хочу поделиться несколькими хаками по оптимизации работы аналитика.

Интерфейсные требования

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

Типизация

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

Типовые элементы экранов: отображение состояний операций, типы и поведение тробберов, правила отображения web-view.
Правила отображения типовых данных: обработка дат, обработка часовых поясов, отображение баланса, правила валидации.
Типизация ошибок: таймаут, ошибки доступа, ошибки запросов, пустые состояния.

Чек-листы

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

Чек-лист для ревью дизайн-макетов можно подсмотреть в статье Саши Маньковской.

Обратная связь

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

Вывод

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

Custom view на Compose

2022-02-09T10:33:58.642Z

Custom view на Compose

Всем привет, меня зовут Николай Широбоков, я — Android-разработчик в e-legion.

В июле Google выпустил стабильную версию Compose. Это вызвало большой интерес в сообществе. Все вокруг стали поговаривать, что эта технология захватит Android-разработку, и скоро все будут писать на Compose.

Я принялся за изучение, заглянул на developer.android.com и нашел различные туториалы по использованию этой библиотекой, но не увидел примеров, как можно создавать кастомные view. Поэтому решил попробовать сделать это и поделиться с вами результатом.

В этой статье покажу, как можно реализовать рыночный график со скроллом и зумом на Compose.

Рисуем свечи

Перед тем, как что-то нарисовать, нужно создать модель.

class Candle(
	val time: LocalDateTime,
	val open: Float,
	val close: Float,
	val high: Float,
	val low: Float
)

Список со свечками я создал, скачав и распарсив файл с Финама. Это не самое интересное, поэтому останавливаться на этом не буду. Если интересно, смотрите код тут.

Для того, чтобы код был чище и лучше читался, сделал класс MarketChartState. В нем буду хранить состояние графика.

class MarketChartState {
	
  	// общий список свечей
	private var candles = listOf<Candle>()

  	// видимое количество свечей
	private var visibleCandleCount by mutableStateOf(60)

  	// размеры области для рисования
	private var viewWidth = 0f
	private var viewHeight = 0f
	
  	// минимальная и максимальная цены видимых свечей
	private val maxPrice by derivedStateOf { visibleCandles.maxOfOrNull { it.high } ?: 0f }
	private val minPrice by derivedStateOf { visibleCandles.minOfOrNull { it.low } ?: 0f }
	
  	// видимые на экране свечи
	val visibleCandles by derivedStateOf {
		if (candles.isNotEmpty()) {
			candles.subList(
				0,
				visibleCandleCount
			)
		} else {
			emptyList()
		}
	}
	
  	fun setViewSize(width: Float, height: Float) {
		viewWidth = width
		viewHeight = height
	}
	
  	// отступ от левого края экрана
	fun xOffset(candle: Candle) =
		viewWidth * visibleCandles.indexOf(candle).toFloat() / visibleCandleCount.toFloat()

  	// отступ от верхнего края экрана
	fun yOffset(value: Float) = viewHeight * (maxPrice - value) / (maxPrice - minPrice)

}

derivedStateOf() создает State, значение для которого вычисляется лямбде. Это значение кешируется, и каждый новый подписчик получает уже закешированное значение. Если в лямбде используется другой State, то при его изменении значение будет пересчитано.

Пример. В лямбде visibleCandles используется visibleCandleCount. При изменении visibleCandleCount значение visibleCandles пересчитается.

Для рисования графика обратился к Composable функции Canvas. В ней есть доступ к DrawScope, в котором можно рисовать линии, прямоугольники, овалы и другие различные элементы.

Canvas(
	modifier = Modifier
		.fillMaxSize()
		.background(Color(0xFF182028))
) {
	
  	// из общей ширины и высоты вычел захардкоженные значения, 
  	// чтобы в освободившейся области рисовать дату и цену.
	val chartWidth = size.width - 128.dp.value
	val chartHeight = size.height - 64.dp.value

  	state.setViewSize(chartWidth, chartHeight)

  	// горизонтальная линия
	drawLine(
		color = Color.White,
		strokeWidth = 2.dp.value,
		start = Offset(0f, chartHeight),
		end = Offset(chartWidth, chartHeight)
	)
	
  	// вертикальная линия
	drawLine(
		color = Color.White,
		strokeWidth = 2.dp.value,
		start = Offset(chartWidth, 0f),
		end = Offset(chartWidth, chartHeight)
	)

  	// отрисовка свечей
	state.visibleCandles.forEach { candle ->
		val xOffset = state.xOffset(candle)
		drawLine(
			color = Color.White,
			strokeWidth = 2.dp.value,
			start = Offset(xOffset, state.yOffset(candle.low)),
			end = Offset(xOffset, state.yOffset(candle.high))
		)
		if (candle.open > candle.close) {
			drawRect(
				color = Color.Red,
				topLeft = Offset(xOffset - 6.dp.value, state.yOffset(candle.open)),
				size = Size(12.dp.value, state.yOffset(candle.close) - state.yOffset(candle.open))
			)
		} else {
			drawRect(
				color = Color.Green,
				topLeft = Offset(xOffset - 6.dp.value, state.yOffset(candle.close)),
				size = Size(12.dp.value, state.yOffset(candle.open) - state.yOffset(candle.close))
			)
		}
	}
}

График, после запуска приложения:

Линии цен

Добавлю 9 ценовых линий. Линии будут располагаться на равном удалении друг от друга по всему экрану.

Изменения в стейте.

val priceLines by derivedStateOf {
	val priceItem = (maxPrice - minPrice) / 10
	mutableListOf<Float>().apply { 
    	repeat(10) { if (it > 0) add(maxPrice - priceItem * it) } 
  }
}

В функции Canvas нарисую линии и текст. В DrawScope нет возможности рисовать текст, поэтому воспользуюсь расширением drawIntoCanvas, в котором можно получить доступ к Canvas к тому самому, который используется для рисования во View, и уже на нем нарисую текст.

state.priceLines.forEach { value: Float ->
	val yOffset = state.yOffset(value)
  	val text = decimalFormat.format(value)
	drawLine(
  	color = Color.White,
		strokeWidth = 1.dp.value,
		start = Offset(0f, yOffset),
		end = Offset(chartWidth, yOffset),
    	pathEffect = PathEffect.dashPathEffect(intervals = floatArrayOf(10f, 20f), phase = 5f)
	)
	drawIntoCanvas {
		textPaint.getTextBounds(text, 0, text.length, bounds)
		val textHeight = bounds.height()
		it.nativeCanvas.drawText(
			text,
			chartWidth + 8.dp.value,
			yOffset + textHeight / 2,
			textPaint
		)
	}
}

Масштабирование

Для этого воспользуюсь готовым решением из библиотеки и добавлю функцию расширение Modifier.transformable к Modifier в Canvas.

Canvas(
	modifier = Modifier
		.fillMaxSize()
		.background(Color(0xFF182028))
		.transformable(state.transformableState)
)

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

val transformableState = TransformableState { zoomChange, _, _ ->
	visibleCandleCount = (visibleCandleCount / zoomChange).roundToInt()
}

Так как в стейте переменные maxPrice и minPrice зависят от видимых свечек, они сразу пересчитываются и также пересчитываются значения в priceLines.

Временные линии

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

Изменения в стейте.

// количество свечек между временными линиями
private var candleInGrid = Float.MAX_VALUE
   
// временные линии
var timeLines by mutableStateOf(listOf<Candle>())

// вычисления линий
fun calculateGridWidth() {
	val candleWidth = viewWidth / visibleCandleCount
	val currentGridWidth = candleInGrid * candleWidth
	when {
		currentGridWidth < MIN_GRID_WIDTH -> {
			candleInGrid = MAX_GRID_WIDTH / candleWidth
			timeLines.value = candles.filterIndexed { index, _ -> index % candleInGrid.roundToInt() == 0 }
		}
		currentGridWidth > MAX_GRID_WIDTH -> {
			candleInGrid = MIN_GRID_WIDTH / candleWidth
			timeLines.value = candles.filterIndexed { index, _ -> index % candleInGrid.roundToInt() == 0 }
		}
	}
}

Изменения в функции Canvas.

state.timeLines.forEach { candle ->
	val offset = state.xOffset(candle)
	if (offset !in 0f..chartWidth) return@forEach
	drawLine(
		color = Color.White,
		strokeWidth = 1.dp.value,
		start = Offset(offset, 0f),
		end = Offset(offset, chartHeight),
		pathEffect = PathEffect.dashPathEffect(intervals = floatArrayOf(10f, 20f), phase = 5f)
	)
	drawIntoCanvas {
		val text = candle.time.format(timeFormatter)
		textPaint.getTextBounds(text, 0, text.length, bounds)
		val textHeight = bounds.height()
		val textWidth = bounds.width()
		it.nativeCanvas.drawText(
			text,
			offset - textWidth / 2,
			chartHeight + 8.dp.value + textHeight,
			textPaint
		)
	}
}

Скролл

График почти готов, осталось добавить скролл. Снова воспользуюсь готовым решением и добавлю функцию расширение Modifier.scrollable к Modifier в Canvas.

Canvas(
	modifier = Modifier
		.fillMaxSize()
		.background(Color(0xFF182028))
		.scrollable(state.scrollableState, Orientation.Horizontal)
		.transformable(state.transformableState)
)

Изменения в стейте.

private val scrollOffset by mutableStateOf(0f)
    
val scrollableState = ScrollableState {
	scrollOffset = if (it > 0) {
		(scrollOffset - it.scrolledCandles).coerceAtLeast(0f)
	} else {
		(scrollOffset - it.scrolledCandles).coerceAtMost(candles.lastIndex.toFloat())
	}
	it
}

// преобразование проскроленного расстояния в проскроленные свечки
private val Float.scrolledCandles: Float
	get() = this * visibleCandleCount.toFloat() / viewWidth
 
// видимые свечи
val visibleCandles by derivedStateOf {
	if (candles.isNotEmpty()) {
		candles.subList(
			scrollOffset.roundToInt().coerceAtLeast(0),
			(scrollOffset.roundToInt() + visibleCandleCount).coerceAtMost(candles.size)
		)
	} else {
		emptyList()
	}
}

Сохраняем состояние

График готов, но при повороте экрана стейт пересоздается. Для сохранения состояния обернул стейт в rememberSaveable и написал Saver.

rememberSaveable(saver = MarketChartState.Saver) { MarketChartState.getState(candles) }

val Saver: Saver<MarketChartState, Any> = listSaver(
	save = { listOf(it.candles, it.scrollOffset, it.visibleCandleCount) },
	restore = {
		getState(
			candles = it[0] as List<Candle>,
			visibleCandleCount = it[2] as Int,
			scrollOffset = it[1] as Float
		)
	}
)

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

Compose оставил у меня только положительные впечатления, и я уверен, что этот подход захватит Android-разработку.

Всем добра и крутых экранов с Compose.

Микросервисы. Не всё то золото, что хайп

2021-10-15T07:10:58.366Z

Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.

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

Для начала давайте синхронизируемся насчёт понятий, которые будут обсуждаться, а потом можно приступить и к самому обсуждению. Итак, микросервисы — что в имени тебе моём?

У меня есть две книги от Сэма Ньюмена: «Проектирование микросервисов» и «От монолита к микросервисам». Они слегка нелогичны, так как вторая книга является по сути предтечей первой, хотя и выпущена сильно позже. Но особый интерес во второй книге для меня вызвали комментарии переводчика. Он ВНЕЗАПНО взял и перевёл наши родненькие «микросервисы» как «микрослужбы», и по всему тексту книги ни одного упоминания о микросервисах не оставил. И наверное, моему возмущению такой отсебятиной не было бы предела, если бы он там же не объяснил свою позицию. А она крайне логична — слово «служба» несёт в себе мощный семантический посыл, который оказывается утраченным при другом переводе. Так что, поразмыслив, я пришёл к выводу, что этот вариант мне даже нравится больше. Действительно, легко представить себе некого служивого, который умеет нести свою службу, от и до, и ни шага в сторону (привет, контракты!). И тогда микрослужбы — это мальчики-с-пальчики, которые вроде и ростом невелики, и помощи от них немного, но при необходимости могут и Гулливера нитками к земле привязать.

Казалось бы, после такого перевода необходимость в определении микросервиса отпадает сама собой. Но есть ещё один вариант от Avery Pennarun, которым невозможно не поделиться:

Микросервисы — это самая экстремально возможная реакция на монолиты.

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

Внимание, вопрос на засыпку. Знаете ли вы, чем отличается монолит от микросервисов?

А если вот так?

Правда, монолит красивее? 😊 Хотя о вкусах не спорят, но как минимум на этой картинке он выглядит проще. Да собственно, так оно и есть. Монолит в разы проще, но при этом предоставляет массу возможностей, от которых приходится отказываться, переходя на микросервисную архитектуру. Ну вот, навскидку:

Просто разрабатывать.

Не нужно думать о куче взаимосвязей — весь проект полностью у тебя перед глазами в любимой IDE. И он либо соберётся и запустится — либо нет.

Легко вносить сквозные изменения.

Разработчики могут протянуть любое сквозное изменение через всю систему (UI-Application-Database), так как владеют ей полностью.

Просто тестировать.

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

Просто развёртывать.

Часто развёртывание заключается в переносе файлов на единственный сервер.

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

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

Вот эти «граждане»:

Сложно разрабатывать разнородную функциональность.
Сложно организовать работу разных команд.
Каждое изменение требует полного переразвёртывания.
Зависимость от постепенно устаревающего стека.
Зависимость от единственного физического узла.
Невозможно масштабировать функциональность отдельно.

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

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

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

Ось X — распределение нагрузки между несколькими идентичными экземплярами.
Ось Y — разделение приложения на функциональные сервисы.
Ось Z — выполнение запросов в зависимости от их атрибутов.

Нетрудно заметить, что монолит может масштабироваться по осям X и Z, не разваливаясь при этом на микросервисы, то есть может сначала развернуться на несколько инстансов за балансировщиком нагрузки, а потом ещё и распределить нагрузку по значениям атрибутов (другими словами, шардироваться). А вот если уже и это не помогает, тогда можно взглянуть и на микросервисы. Украдкой, с опаской, но взглянуть.

Прежде чем всё-таки перейти на микросервисы, ответьте на следующие вопросы:

Ваш монолит разбит на связные модули с минимальным количеством внешних взаимодействий?
Вы рассмотрели все потенциальные варианты масштабирования монолита?
Не подойдёт ли для ваших задач компромиссное решение, например, модульный и/или распределённый монолит или цитадель?

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

Что здесь интересного?

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

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

Но я подозреваю, что может возникнуть резонный вопрос — почему я всеми силами пытаюсь склонить читателей к неиспользованию микросервисов? Почему настолько категоричен в отношении виновников нашего торжества (читай, статьи)?

При всей простоте идеи микросервисы — крайне сложная вещь, которая несёт с собой другие сложные вещи. Самое важное, что необходимо держать в голове следующее: микросервисные системы — это распределённые системы со всеми вытекающими последствиями. Если при прочтении предыдущего предложения ваши волосы не встали дыбом, то могу вас только поздравить. Либо с тем, что вы настолько умны (и я вам очень сильно завидую), либо с тем, что у вас впереди множество открытий чудных.

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

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

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

Ну а теперь о болях:

Сложно подобрать подходящее разбиение на сервисы.
Сложность распределённых систем затрудняет разработку, тестирование и развёртывание.
Развёртывание функциональности, охватывающей несколько сервисов, требует тщательной координации.
Сложно определить момент, когда переход на микросервисы станет обоснованным.
Самая большая боль, как я уже сказал раньше — это то, что система переходит в класс распределенных, а там ох сколько проблем. Но как говорится, мыши плакали, кололись, но продолжали хайповать. И конечно же, неразрешимых проблем нет, при большом желании можно и JavaScript сделать серверным языком. Желание было, возможности тоже — вот и решения нашлись. Возможно, благодаря этим решениям и поддерживается технический прогресс. Так что не всё то плохо, что кажется таким. И я для себя выделил некоторые проблемы и их решения, которые хоть как-то можно привязать к микросервисам, причём не всегда будут прослеживаться причинно-следственные и пространственно-временные связи, но определённая логика в этом есть. Вот, смотрите:

— Автономное развёртывание:

контейнеры;
Docker;
Kubernetes (K8s).

— Сетевые вызовы:

cериализованные очереди;
предохранители;
дублирование соединений и сервисов.

— Координация множества сервисов:

оркестрация;
хореография;
Service Mesh (istio, linkerd, envoy).

— Пользовательский интерфейс:

API Gateway;
фрагменты;
микрофронтенды;
BFF.

— Безопасность:

OpenID;
Single Sign-On (SSO);
JWT.

— Распределённые транзакции:

саги;
консенсус.

— Генерация отчетов:

репликация;
CQRS.

— Разные рабочие окружения:

сервера конфигураций;
решения для развёртывания;
канареечные и сине-зеленые выпуски;
devOps-инженеры.

—Тестирование:

тесты на основе запросов потребителей (CDC-тесты) вместо сквозных.

— Журналирование:

сквозные идентификаторы.

Ну ок, вы всё-таки решились. Я сдаюсь. Микросервисы — ваше всё, и возражений не принимается. Как сделать хороший микросервис? Да практически так же, как и хороший модульный монолит. Но есть ещё несколько пунктиков:

Его выделение обосновано (есть спец-команда, спец-требования, спец-ограничения, спец-циалисты).
У него сильное внутреннее сцепление и слабая внешняя связанность.
Он выполняет четко определённую функциональность.
Есть настроенное внешнее окружение и шаблон сервиса, который умеет в этом окружении жить и взаимодействовать.
Интеграции — обычно хороший вариант для микросервиса.

А у меня на этом всё, надеюсь, эта статья будет для вас полезной.

e-legion рекомендует :: ивенты для аналитика

2021-09-14T11:12:50.795Z

Лето закончилось 😿, а значит наступает пора айтишного движа 😉

В этом выпуске e-Legion рекомендует Анастасия Московкина, руководитель отдела анализа, рассказывает об интересных для аналитиков мероприятиях и не только.

И сразу приглашаем всех 29 сентября на ламповую встречу аналитиков из e-Legion, EPAM Systems и 2GIS, организатором и модератором которой выступит Анастасия. Коллеги расскажут о своем уникальном опыте входа в профессию, что нужно для развития и ответят на вопросы аудитории. Регистрируйся по ссылке, будет уютно и интересно!

Передаем слово Насте. Приятного чтения!

Привет! Начну с литературы:

Отличные новости! Уже начали рассылать спонсорам печатную русскоязычную версию BABOK 3.0

BABOK (Business Analysis Body of Knowledge) — это свод знаний по бизнес-аналитике, составляемый Международным институтом бизнес-анализа IIBA.

Ивенты по календарю:

16-17 сентября, Санкт-Петербург, TeamLead Conf. Пока я там не участвовала ни в роли участника, ни в роли спикера. Но к записям с докладов на youtube я обращаюсь. Например, слушала про распределение командных ролей по Белбину (а мы тоже тестируемся, было интересно, что об этом говорят умные люди) и про карьерные уровни в Wargaming.
25 сентября, Санкт-Петербург, Точка сборки. Я уже купила билет, а вы? Это первая площадка, где я дебютировала в качестве спикера. Поэтому Точка сборки в моём сердечке.
29 сентября, онлайн, e-Legion analyst meetup #3 «Аналитик в IT: как распознать в себе аналитика?». Будет ламповый разговор с аналитиками о том, как ребята пришли в профессию.
13 октября, Москва, MBLT+ — Международная мобильная конференция. Еду обязательно, потому что это конференция про тренды в области мобильной разработки, прикладная тема для меня.*

* Конференция перенесена на 2022 год.

19-20 ноября, Москва, Analyst Days. Считаю, что конференция не нуждается в представлении) Зато могу анонсировать свой доклад! Я и руководитель отдела дизайна Никита Жеребцов будем рассказывать про анализ конкурентов. Будет интересно!

Обучение:

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

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

e-legion рекомендует: интересные IT-события этой осени

2021-09-01T12:53:34.054Z

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

Прочь осеннюю хандру! Для поднятия морального духа и для увеличения вовлеченности в IT-просвещение мы собрали подборку интересных IT-ивентов приближающейся осени 2021.

Большинство мероприятий в списке ориентированы либо на разработчиков, либо на представителей крупного бизнеса, но есть одна конференция (под №7), которая объединяет в себе оба эти направления.

Увлекательного чтения и до встречи на мероприятиях.

1. PyCon Russia 2021

Место проведения: Природный курорт Клязьма Резорт в 12 км. от Москвы
Даты: 5 и 6 сентября
Аудитория: опытные python-разработчики, тимлиды, python-евангелисты, а также начинающие питонисты
Стоимость участия на 30 августа: 22 000 ₽

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

2. Saint TeamLead Conf

Место проведения: Санкт-Петербург, Красногвардейская пл., 3, DESIGN DISTRICT DAA in SPB
Даты: 16 и 17 сентября
Аудитория: профессиональная конференция только для тимлидов
Стоимость участия на 30 августа: 48 000 ₽

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

Обратите внимание, на конференции будет организована зона, свободная от COVID-19.

3. QA-конференция QAASP

Место проведения: онлайн
Дата: 17 сентября
Аудитория: middle и senior QA инженеры
Стоимость участия на 30.08: от 3 230 ₽

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

4. Moscow Python Conf++ 2021

Место проведения: Москва, пл. Европы, 2, Radisson Slavyanskaya
Даты: 27 и 28 сентября
Аудитория: Python-разработчики
Стоимость участия на 30.08: 44 000 ₽ оффлайн, 22 000₽ онлайн

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

На конференции будет организована зона, свободная от COVID-19.

5. Big Data Days Moscow Online Edition

Место проведения: онлайн
Даты: 28 и 30 сентября
Аудитория: Big Data scientist
Стоимость участия на 30.08: от 24 000 ₽ до 60 000 ₽

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

6. FrontendConf 2021

Место проведения: Москва, пл. Европы, 2, Radisson Slavyanskaya
Даты: 11 и 12 октября
Аудитория: Frontend-разработчики
Стоимость участия на 30.08: 40 000 ₽

Профессиональная конференция Frontend Conf 2021 посвящена всем аспектам разработки клиентской части веб-проектов: дизайн, юзабилити, вёрстка, JavaScript и веб-медиа. На конференции будет организована зона, свободная от COVID-19.

7. Международная мобильная конференция MBLT+*

Место проведения: Москва, ул. Покровка, 47, ЦДП
Дата: 13 октября
Аудитория: здесь встретятся представители крупного бизнеса и разработчики
Стоимость участия на 30.08: 16 000 ₽

В этом году на конференции будет организовано 4 трека по направлениям бизнес, iOs и Android разработка, секция для digital-агентств. На конференцию традиционно выступают спикеры-представители крупнейших брендов из разных стран мира.

Организатор e-Legion анонсирует, что MBLT+ станет площадкой для обучения и нетворкинга, где вы сможете узнать мнения экспертов и поделиться идеями, которые помогут создать и сформировать будущее цифровых сервисов и продуктов.

* Конференция перенесена на 2022 год.

8. DevOops

Место проведения: онлайн
Даты: 8 и 11 ноября
Аудитория: DevOps-инженеры
Стоимость участия на 30.08: от 12 000 ₽ до 24 000 ₽

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

9. C++ Russia

Место проведения: онлайн
Даты: 15-18 ноября
Аудитория: профессиональная конференция для опытных C++ разработчиков
Стоимость участия на 30.08: от 12 000 ₽ до 24 000 ₽

На этой конференции вас ждут хардкорные технические доклады, посвященные C++: concurrency, производительность, архитектура и инфраструктурные решения.

10. Mobius 2021 Moscow

Место проведения: онлайн
Даты: 22-25 ноября
Аудитория: IOS-разработчики, Android-разработчики, backend разработчики, Java-разработчики, архитекторы, тестировщики
Стоимость участия на 30.08: от 12 000 ₽ до 24 000 ₽

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

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

Вместе мы создаем будущее цифровой инфраструктуры! 💙

MBLT возвращается

2021-08-22T09:36:04.986Z

Кто: e-Legion

Что: Мобильная конференция MBLT+

Для кого: Бизнеса и разработки

Когда: 2022-й год

Где: Москва, ЦДП

В этой статье мы расскажем, почему конференции MBLT и MBLT Dev являются знаковыми событиями в индустрии с 2012 года, и почему в 2022-м году ты должен быть на MBLT+!

Следи за последними новостями конференции в нашем Telegram-канале.

Как это было?

10+ конференций

300+ докладов

4000+ участников

С 2012 года MBLT и MBLT Dev собирают вместе и объединяют вокруг сообщества специалистов мобильной разработки со всего мира. Так, у нас выступали спикеры из Facebook, Google, Shazam, Uber, Netflix и др.

Например, к нам приезжали:

Кей Шимада, футуролог из Dentsu, с презентацией о мобильных инновациях в Японии: «Инновации бессмысленны, если они не приносят долгосрочной пользы».

Канадский блоггер Эша Фюрроу, iOS-разработчик онлайн галереи Artsy и автор нескольких книг про iOS-разработку, с докладом «Реактивное программирование на Swift».John C. Fox, iOS UI Engineer Netflix из США, рассказал о высококачественной локализации приложения, а также о работе с агрессивными сетевыми условиями и A/B-тестировании.

На нашем Youtube-канале есть еще много классных докладов от интересных спикеров, подпишись, чтобы не потерять.

Помимо актуальных и топовых докладов на конференциях мы организуем много других полезных активностей, например, на MBLT19 мы провели битву продуктов! Менеджеры продуктов приложений операторов МТС, Мегафон и Tele2 устроили баттл на сцене конференции, чтобы определить, какое приложение удобнее.

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

Ну и куда же без конкурсов, Codelabs и прочих интерактивов.

Что нас ждет в следующем году?

MBLT возвращается в новом формате! В 2022-м году e-Legion впервые проведет конференцию, объединяющую бизнес и разработку — MBLT+.

На трех треках (Business, iOS, Android) конференции выступят топ-менеджеры IT компаний, Middle- и Senior-разработчики со всего мира.

Состав спикеров MBLT+ будет как всегда звездный:

Хедлайнером конференции выступит Лука Стефанутти из Австрии!

Лука — руководитель отдела продуктового маркетинга компании adidas Runtastic. Он возглавляет команду Running Growth, которая отвечает за развитие приложений adidas Running. На сегодняшний день его команда предоставляет одно из лучших пользовательских предложений в категории «Здоровье и фитнес», вовлекая таким образом всё больше и больше людей в спорт.

Даниил Петин, операционный директор DiDi в России, расскажет о масштабировании бизнеса в период мирового кризиса с помощью внедрения инноваций.

В конференции также примут участие спикеры из компаний-лидеров рынка: Amazon, EPAM Systems, IoT Tribe, Google, VisionLabs и др.

Нетворкинг для всех!

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

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

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

Вечером оставайся на неформальную часть — afterparty с подарками, вином и DJ-сетом под космические инсталляции.

Участие в MBLT+ — это:

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

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

Комфорт. Кофе весь день, напитки, обед и ужин на вечеринке. Оборудованные пространства для работы, free wi-fi, лаунж-зоны.

Фан. Интерактивы, VR-аттракционы и немного AR-искусства.

Больше подробностей ты найдешь на сайте MBLT+.

Легионеры в экспедиции на Белое море

2021-08-19T20:52:03.659Z

Неделю назад завершилась чудесная экспедиция e-Legion на Белое море! Мы провели неделю на Беломорской биологической станции «Картеш» (далее ББС «Картеш»).Для начала стоит отметить, что «Картеш» — научная организация и не принимает туристов, но, так как e-Legion сотрудничает с ББС уже более 6 лет, мы смогли посетить ее и даже поучаствовать в жизни биостанции.

Итак, экспедиция начинается!

Командой из шести человек во главе с нашим генеральным директором Артёмом Михайловым мы отправились в путь.

Дорога заняла около суток: из Санкт-Петербурга на поезде мы добрались до поселка Чупа в северной Карелии, откуда до биостанции мы плыли на судне 2,5 часа.

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

Интересный факт: породам геологических обнажений мыса Картещ - 2,8-3,2 миллиарда лет.

Место для биостанции было выбрано по ряду причин:

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

Постоянно на ББС «Картеш» живет только технический персонал, научные сотрудники приезжают лишь на какое-то время. Например, чтобы провести эксперимент или собрать необходимые данные и образцы. В летнее время на биостанции в среднем находится около 50 человек.

Чем занимаются сотрудники на самой станции?

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

К примеру, на биостанции изучают асцидий, медуз, морских звезд, морских пауков и многих других обитателей Белого моря.

Традиционно главными направлениями научных работ на ББС являются:

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

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

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

Расскажем только о трех:

1. Мониторинг зоопланктона

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

Авторы: Adriana Zingone, Domenico D'Alelio, Matia Grazia Mazzocchi, Marina Montresor, DianaSarno, LTER-MC team

Это один из самых продолжительных проектов по изучению многолетней динамики зоопланктона в мире! Сходные по длительности и подробности исследования проводятся в Англии, Германии и США.

Летом зоопланктон собирают с борта судна один раз в 10 дней, а зимой – один–два раза в месяц через прорубь во льду.

В этом проекте сотрудники ББС:

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

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

2. Технология по выращиванию мидий

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

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

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

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

Беломорская мидия считается одной из самых вкусных! Смело спрашивайте беломорские мидии в ресторанах Петербурга.

3. Ядовитая губка

Знакомьтесь с этой красавицей: её зовут Halichondria panicea.

Автор: Minette Layne

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

Например, в Японии уже сейчас производят лекарство “Халавен”. Этот препарат содержит вещество, выделенное из другой морской губки Halichondria okadai.

e-Legion и ББС “Картеш”

e-Legion поддерживает биостанцию «Картеш» уже более 6 лет.

По инициативе и при поддержке нашего генерального директора, Артёма Михайлова, в 2015 году вся территория станции была покрыта сетью wi-fi специально для приезжающих гостей.

CEO e-Legion - Артем Михайлов

Для сотрудников биостанции существовала своя закрытая сеть. Но на ББС часто приезжают учёные из различных институтов России и мира, которые теперь могут пользоваться wi-fi сетью, созданной специально для них.

За сезон биостанцию посещают более сотни человек, чтобы провести совместные исследования с сотрудниками ББС или обменяться знаниями.

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

Как мы говорили выше, «Картеш» — научная организация и не принимает туристов, поэтому мы постарались адаптироваться под условия станции и помочь сотрудникам, чем могли:

Дежурили на кухне

Собирали мусор в лесу и по берегу

Помогали расчищать линию передач

Оказывали другую помощь

Беломорская биологическая станция «Картеш» — уникальное по красоте и атмосфере место. Каждый человек на станции выполняет огромный, часто недооценённый, труд.

Спасибо сотрудникам «Картеш» за их гостеприимство и доброту!

Алгоритм успешного собеседования

2021-07-15T14:07:29.710Z

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

Наша чудесная рекрутёр Александра Широкина делится советами и проверенными личными лайфхаками о том, как подготовиться к успешному (даже идеальному!) собеседованию.

7 заповедей подготовки

Пункт №1: Напиши хорошее резюме, лаконичное, но не скудное, поскольку это известный факт, что рекрутёр тратит на просмотр каждого резюме не более 30 секунд.

Хорошее резюме невозможно без пункта №2: заполни блок «О себе», написав там, то, что посчитаешь нужным, например, опиши свои хобби и/или soft skills. Если меняешь специальность, расскажи, почему и об опыте, который связывает тебя с ней. Возможно, стоит дополнительно упомянуть об интересных проектах, в реализации которых принимал участие.

Пункт №3: изучи описание компании и вакансии. На самом деле ты можешь уже на этом этапе не совпадать с ценностями компании и/или требованиями к желаемому кандидату. Не трать время: ни своё, ни рекрутёра. Посмотри соцсети и блоги компании, это очень полезно, например, ты можешь найти информацию о человеке, с которым у тебя будет проходить собеседование. Если это IT-компания, поищи её блоги на habr, linkedin, medium.

Пункт №4: прочитай свое резюме перед тем, как отправишься на собеседование. Бывают такие случаи, что человек просто забывает, что там написано, и не может ответить на вопросы рекрутера, даже на самый простой! Тебе ведь не нужны неловкие ситуации.

Сюда же и пункт №5: не опаздывай и не приходи сильно заранее. Не надо приезжать в офис компании за полчаса и сидеть на диванчике рядом с рекрутёром, ну и опаздывать понятно — это моветон.

Даже в IT-компаниях не всё бывает ладно с техникой, от этого появился обязательный пункт №6 перед собеседованием: проверь свои девайсы и потести сервисы заранее, если встреча проходит онлайн. Во избежании пункта №5, да и просто для спокойствия.

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

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

Топ-10 советов

Собери рекомендации заранее, чтобы всегда быть наготове.
Поешь накануне или перед самым интервью, если любишь, выпей кофе — это бодрит.
Отключи уведомления на телефоне, во всех мессенджерах, почтах и социальных сетях.
Запланируй чуть больше времени, чем требуется. Это избавит тебя от лишних нервов, и ты не будешь опаздывать на следующую встречу.
Улыбка располагает к себе рекрутёра. Улыбайся!
Надень комфортную одежду, но при этом важно выглядеть опрятно.
Почисти свои социальные сети, если есть что-то, к чему можно придраться, ну или просто закрой профиль :)
Подумай о своих хобби. Прогулки, сериалы или компьютерные игры — это тоже хобби!
Будь собой, ведь нет ничего прекраснее (мотивирующая минутка).
А ещё животные в кадре разряжают атмосферу. Не бойся, что твои подопечные появятся в кадре во время интервью. Это мило :)

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

О чём нужно сказать на собеседовании? (Обязательно нужно)

Во-первых, это нормально говорить о деньгах. Мы всё-таки не рабы, и все пришли зарабатывать деньги. Но и только о деньгах говорить не стоит, работа должна приносить удовольствие (в первую очередь на это надеятся рекрутеры).

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

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

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

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

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

О чем не надо (ни при каких условиях) говорить во время собеседования?

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

Не матерись, не шути неуместные шутки и не подкатывай к рекрутёру, это всё-таки деловая встреча.

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

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

Лекарство от нервов

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

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

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

Как-то так, всё очень легко, никаких махинаций, раскладов таро и танцев с бубном, просто алгоритм, которого нужно придерживаться на каждом собеседовании. Мы будем рады, если ты будешь следовать этим советам на собеседовании у нас в компании! Шансы попасть в команду сразу увеличаться. Мы желаем тебе удачи и ждём на собеседованиях, а вакансии в e-legion ты всегда можешь посмотреть на нашем сайте https://www.e-legion.ru/vacancies/ :)

Продуманные макеты или как предугадать вопросы коллег (+ чек-лист)

2021-07-06T09:41:11.197Z

Ты передал в разработку крутые макеты, уже спишь и видишь их на проде, но разработчики и QA не перестают писать тебе, чтобы уточнить всё новые детали. Знакомая ситуация? В этой статье я расскажу о том, как подходить к дизайну более вдумчиво и закрывать большую часть вопросов коллег из других отделов еще до их появления. А также поделюсь чек-листом, который будет полезен дизайнерам мобильных приложений для проверки своих творений перед передачей их в разработку.

Состояния экранов

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

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

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

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

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

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

данные получены
данные отсутствуют
данные загружаются
ошибка при получении данных

Данные на экране

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

Посмотрите, как ваш макет будет выглядеть и для «Ивана Иванова», и «Константина Константинопольского». Комфортно должно быть всем.

Это касается и заполняемости содержимого экрана. Что, если пользователь напишет в строке с отзывом «Классно»? А что, если он сильно расстроился и хочет вылить душу в этом маленьком инпуте?

Всегда думайте и про «маленьких», и про «больших».

Элементы интерфейса

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

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

Если приложение загружает какой-то контент (изображения, видео…) стоит предусмотреть заглушку для него. Это поможет избежать белых дыр в интерфейсе.

Девайс

На первых порах моей работы дизайнером данный пункт был просто моей болью. Я могла подготовить все макеты для обеих платформ, согласовать, выгрузить для разработки и расслабить булки, а потом ко мне внезапно подходили с вопросом: «А на планшете как оно будет?». Если ваше приложение работает не только на смартфонах под iOS и Android, но еще и на планшетах, не забудьте включить такой пункт в свой чек-лист для проверки.

Есть еще один момент, который я бы назвала не правилом, а особым случаем, который стоит держать в уме. Мы с коллегами всегда готовим макеты для каждой платформы в одном размере. Например, сейчас для iOS мы используем iPhone 11 Pro. У многих пользователей девайсы могут оказаться меньше. Поэтому при подготовке макета представьте, что увидит человек с iPhone 8 или SE. В «особо тяжелых случаях» подготовьте дополнительный макет. Вам не сложно, а разработчику будет намного проще.

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

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

Сейчас чек-лист успешно применяется на одном из проектов e-Legion при работе с дизайнерами из сторонней компании.

#дизайн

#полезныесоветы

#макеты

#мобильныеприложения

#чеклисты

Тренды дизайна цифровых продуктов: как им соответствовать

2021-07-06T09:34:32.997Z

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

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

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

Визуальные
Технологические
Тренды рынка
Тренды пользовательского опыта

Итак, давайте попробуем разобрать их по отдельности.

Пункт 1. Визуальные тренды

Если после 5 лет жизни на необитаемом острове меня спросят: какие сейчас тренды дизайна — я отвечу минимализм и акцентная типографика.

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

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

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

Возникает вопрос: как отличаться? Можно, например, коммуникационным дизайном, можно классными паттернами взаимодействия или моушеном.

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

Кстати, про визуальные тренды есть ироничная лекция Александра Ковальского из Creativepeople на Design Prosmotr. Если интересна эта тема, найдите на ютубе, он очень хорошо раскрыл тему.

Как соответствовать

Нанять талантливых людей в свою команду или привлечь талантливое агентство. Есть куча примеров коллабораций, результатами которых стал очень мощный визуальный язык: Сбер со Щукой, Яндекс с ONY, Кухня на районе и White Russian.

Ищите своё, будьте смелее и работайте с талантливыми людьми.

Пункт 2. Технологические тренды

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

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

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

Из конкретных трендов я бы выделил:

AR, VR, MR

Такие технологии сейчас используются в основном в сфере интертеймента, но, думаю, скоро они появятся и в сервисных приложениях. Например, уже сейчас ребята из студии Kelnik применяют технологию VR при продаже квартир. И таких историй будет только больше.

Голосовые интерфейсы

Уже существуют «Siri Shortcuts», позволяющие интегрировать часть функций сервисов в голосовой помощник. Кроме того, все вы знаете Алису от Яндекса, с которой можно вести разговоры о погоде и попросить включить музыку.

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

Internet of Things

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

Например, SberDevices недавно получили Red Dot Design Award за СберПортал — абсолютно прекраснейший продукт, в который уже сейчас встраиваются другие сервисы. К примеру, через девайс ребенок может проходить задания с дополненной реальностью от Skyeng. Сервисы интегрируются, используя возможности и функциональности друг друга. Вы только посмотрите, как это круто.

Развитая технологическая база

Это несколько абстрактный пункт, здесь я имею в виду появление новых технологий, которые откроют новые паттерны в дизайне продуктов. Например, 5G, eSIM, биометрическая идентификация.

Как соответствовать

Отслеживать основные технологические конференции, развивать технологическое партнерство. Звучит банально, знаю, но лучше способа не найти. Смотрите или посещайте конференции Facebook F8, WWDC, AWS re:Invent, Google i/o, YaC, SmartDev и др., чтобы держать руку на пульсе. Отслеживайте конкурентов, изменения на рынке, сотрудничайте с игроками из своего сегмента бизнеса, только так можно поспеть за быстро развивающимися технологиями.

Пункт 3. Тренды рынка

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

Высокая скорость разработки

Time to market сегодня важен, как никогда. Темп внедрения новых функций и запуска продуктов очень высокий.

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

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

Экосистемы и супераппы

Здесь достаточно очевидные примеры: Яндекс.Go, ВКонтакте, Тинькофф. Но кроме них на рынке есть еще ряд компаний развивающих или планирующих развитие экосистем: МТС, ВТБ, Магнит, Сбер, и т.д. Этот список будет только пополняться.

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

Интеграции и партнерства

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

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

Как соответствовать

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

Пункт 4. Тренды пользовательского опыта

Здесь я также выделяю несколько факторов, определяющих последние тренды:

Технологическое совершенство

Наш рынок сформировал среду, где пользователь привык к технологически очень развитым продуктам. Например, Россия была на 2 месте в мире по количеству транзакций через Apple Pay в 2020 году.

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

Персонализация

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

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

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

Тинькофф-банк. На основе моих трат сервис предлагает мне открыть их Инвест копилку. То есть анализируя моё поведение, он предлагает мне свой продукт, который может быть мне полезен. И, что важно, делает это через персональную коммуникацию, используя данные, как reason to believe.

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

Инклюзивность

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

В широком — доступность продукта для категорий людей, имеющих ситуативные, временные или постоянные ограничения. Тема обширная, подробно останавливаться не буду. Скажу лишь, что это не только тренд, но и возможность увеличить свою аудиторию. И в качестве материала для изучения могу посоветовать книгу про доступность от Dodo и телеграм-канал «Не исключение» от Валерии Курмак.

Устойчивое развитие (экономика + экология + социальная сфера)

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

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

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

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

Забота о пользователях

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

Инстаграм. Сейчас существует определенный тренд на осознанное времяпрепровождение в digital-пространстве. Уже устраивали себе digital-detox? Инстаграм реагирует на этот запрос от пользователя: приложение позволяет отследить, сколько времени я провожу в нем, установить лимиты на день/неделю, помогает регулировать и планировать свое время.

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

Основная идея, думаю, кристально ясна — чем внимательнее вы к пользователю, тем лояльнее он относится к вам. Даже если появится просадка каких-то метрик, как в примере с Инстаграмом, где пользователь может начать сознательно ограничивать свое время в приложении, метрика NPS пойдет вверх. Ведь получается, что сервису важнее забота о своем клиенте, нежели значения MAU/DAU.

Как соответствовать

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

Подводя итог

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

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