Pull to refresh
21
0

Solution Architect

Send message

Спасибо за предложения. Да мысли конечно есть. Но вот делать самим или отдать создание таких пакетов партнерам.

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

Можно в фигме посмотреть/покритиковать наши итерации
https://www.figma.com/file/50bjKfOyF9KMn4IUwWnq96/Platform-Atomic

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

Так же есть клиенты/партнеры которые пользуются то чем есть Virto Commerce - Headless платформа и подключают API к своему интерфейсу - они знают своих клиентов, и могу сделать интерфейс гораздо лучше чем из мы коробки.

Спасибо за комментарий. Постараюсь дополнить.

Первое, Integration Middleware как паттерн и Logic Apps как продукт уже как несколько лет выбраны у нас как основа для построения интеграций и прекрасно себя показывают в деле.

Из плюсов:

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

  2. структурируются и описываются потоки данных - фактически интеграция становится видна как потоки документов.

  3. следующим плюсом наличия документов - это отладка - все видно, что куда пошло, можно снять данные, исправить и повторить с места ошибки.

  4. интеграции можно хранить в GitHub репозитории и деплоить

  5. low code - понятно сложные бизнес логику не напишешь, с другой стороны это и хорошо - есть какие-то границы когда нужен программист.

  6. В облаке - стоит не дорого, масштабирование.

Из минусов:

  1. Привязка к Azure, хотя недавно MS дали возможность запускать в своем Docker контейнере, есть клиенты которые перенесли подход на DellBoomi, есть и другие продукты.

  2. Сначала может показаться что Point-to-point написать в коде быстрее и проще.

Сложности:

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

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

  3. Не у всех системы API готов и работает правильно под Асинхронные сценарии. особенно, что касается поиска измененных объектов или выброс webhocks.

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

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

Попробуем добавить, правда там и ценник уже не такой интересный.

У нас в компании написание в данном случае E2E теста — это процесс разработки.

BA закладывает в описание какие user-story должны быть покрыты E2E тестом и кто как не разработчик в момент реализации, может все это подготовить и реализовать по уже подготовленному сценарию.

Да согласен с вами, что проверять в UI сложно, так же наличие E2E — не исключает наличие других тестов, как вообще работы QA. Но из опыта, я вижу как E2E повышают качество проекта и не дают проскочить ошибкам в бизнес сценариях на продукцию.

Это нам позволяет делать обновление разных модулей быстрее и избегать ручной работы.
У нас основной опыт использования Protractor именно вместе с AngularJS. Но если вы посмотрите в интернете статьи как End-to-end testing with protractor for nonangular applications, то все запускается (правда с небольшими бубнами) и успешно работает.
Для написания User-Story мы используем шаблон Given-When-Then. Он наиболее удачно походит для дальнейшего построения E2E теста. Вот как простой пример:

GIVEN the account activation page is open
WHEN
EITHER «Create new password», «Confirm password»
OR «I agree with the terms and conditions» checkbox isn't filled in
THEN the «Activate» button should be disabled

Он потом легко транслируется разработчиками в E2E тест.

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

Данную проблему можно кардинально решить
Вариант 1. Оставить на сайте только вход через соц.сети.
Вариант 2. Сделать регистрацию через телефон и СМС подтверждение.

Мне кажется что стандартную регистрация с её проблемами и сложностью создания пароля (с длиной, разным регистром, спец символами) для клиента на большинстве сайтов можно смело убирать.
Сейчас частично работаем с Ян*екс. Такое ощущение что они еще активно пилят систему и обновляют. Подключили три месяца назад, вот проблемы с которыми мы столкнулись:
— При проведении они чекают 1 раз. Если наш сервис не принял информацию о платеже (например обновление, баг и т.д.) то Offline платежи подвисают у большого брата, а Online отменяются. Чтобы клиенту вернуть подвисший платеж надо его или хитро проталкивать (есть целый регламент)))) или писать в суппорт — решение рассматривается 30 дней. Автоматически пропихнуть нам они не могу. Вернее могут но говорят что опять же в течение двух — трех недель.
— Конфликты с переходом на страницы 3D Secure Банка, видим описание ошибки (присылает клиент) нам СП Ян*екс говорит что у них норм и проблема на стороне банка, и пусть клиент обращается в банк. Понятно что нам приходится помогать клиенту.
— Иногда проскакивают ошибки — неделя назад было двойное списание с карт по платежам, ответ от СП один у нас все хорошо — проблемы у банков, пусть клиент обращается в свой банк за возвратом.
— Долгое время ответа от СП, некоторые обращения висят до сих пор.
— Возвраты по Offline платежи обещали, пили, пили, пили, прошли обещанные сроки, но по моему так не допили )

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

А так если смотреть:
— передав клиента другому сервису мы увеличиваем на несколько шагов путь к оплате
— интерфейсы не всегда простые для клиента, да в несколько шагов + отличаются стилем от сайта (кто-то дает допиливать, кто-то нет)
— косячат все ) — падает процессинг, подвисают платежи, двойные списания
— на различных способах отсутствует механизм возврата, особенно Offline платежи
— плохо работает служба поддержки, если клиент все-таки звонит в процессинговую компанию.
— часто пинают что проблема у вас или проблема банка, сами общаться с банком отказываются, предлагая это сделать или клиенту или нам вместе с клиентом )
Спасибо за статью. На наших проектах мы устали от того что платежные агрегаторы косячат (даже Ян*екс), и поэтому анализируем возможность начать принимать оплату заказов картой на нашем сайте. Было много вопросов по поводу PCI DSS и т.д., ваша статья очень вовремя.
Уж простите, но не верю я в такое визуальное программирование.
Лично мне работать со Stapwatch классом показалось не очень удобно. Написал простую оболочку StopwatchOperation задача которой быстро обвернуть код и вывести в трейс (как пример) результат замера.

Пример использования:
using (new StopwatchOperation("TODO: Ваше имя тут"))
{
	// Мой код тут
}


Код:
public class StopwatchOperation: IDisposable
	{
		public string Name { get; set; }
		protected Stopwatch InnerStopwatch { get; set; }

		public StopwatchOperation(string name)
		{
			this.InnerStopwatch = new Stopwatch();
			this.Name = name;

			this.InnerStopwatch.Start();
		}

		#region IDisposable Members

	public void Dispose()
	{
		Dispose(true);
		GC.SuppressFinalize(this);
	}


	protected virtual void Dispose(bool disposing)
	{
		if (disposing)
		{
			if(this.InnerStopwatch!=null)
			{
				this.InnerStopwatch.Stop();

				Trace.WriteLine(string.Format("Duration of '{0}' is {1} milliseconds.", this.Name, this.InnerStopwatch.ElapsedMilliseconds));

				this.InnerStopwatch = null;
			}
		}
	}
	#endregion
}
Почему то забыли про FastStone Image Viewer faststone.org. Пользуюсь давно очень шустрая и полный набор начальных инстрементов.
Спасибо за труд.
Не мучайтесь, возьмите нормальные средства разработки.
Чем больше возможностей изучать программирование для детей тем лучше. Только стоит помнить, когда нужно прекращать использовать визуальные редакторы и переходить на обычные инструменты.

Вернее я считаю что в данных средах нужно обучать детей основам алгоритмов и языков программирования, а сразу после закрепления материала показывать как это делается или на Java или на C#. И толку будет больше и не будет мучить детей когда захочется сделать что-то серьёзнее.

Спасибо, в торрент стоило сразу выкладывать
Из-за софта. От простых Send2Kindle, 7-zip, Total Commander, Diamond Tools и Notepad+ до Visual Studio.

Information

Rating
Does not participate
Location
Калининградская обл., Россия
Date of birth
Registered
Activity