Pull to refresh
14
Karma
0
Rating

Эффективное тестирование верстки

В общем, разобрался я — есть же декораторы в Storybook и в них контекст каждой истории приезжает — в случае с storybook/vue это выглядит так:
.addDecorator((storyFn, constext) => {
  ...
  return storyFn(context);
})

С помощью контекста выясняем что за история сейчас будет показываться (св-во name) ну и формируем нужный нам глобальный контекст:
if (context.name === 'Story with special state') {
  Vue.use({
    install: (vueObj) => {
      vueObj.prototype.$globalProp = ...;
    }
  });

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

В любом случае спасибо за ликбез)

Эффективное тестирование верстки

Спасибо за столь развернутый ответ)
Таким образом в каждой истории перед маунтом мы будем подменять сущности на нужные моки и истории будут изолированы.

Вопрос мой как раз про сей момент, на самом деле. Как там запросы мокать и компонент с минимумом логики оформлять (без походов в сеть) — тут все понятно, не впервой. Вот как кастомный контекст подсунуть во Vue компонент, в котором оный как раз представлен в виде глобальной переменной — это не получается пока осилить. vue-test-utils позволяет в mount передавать mocks и при написании юнит тестов мы эту проблему решаем ровно таким образом. Вот в случае со storybook/vue не припоминаете что-нибудь подобное?

Эффективное тестирование верстки

все-таки завел я эту машинерию — действительно пришлось сильно с webpack повозиться.

Вот Вы упомянули vue-test-utils и jest — подозреваю как-то они использовались, чтобы мокать глобальные параметры/запросы в stories. Не поделитесь опытом как это делается? А то storybook/vue lack of documentation и сколько ни рыл просторы инета по этой казалось бы основнополагающей теме — безрезультатно( Если есть пример кода где манкипатчится какой-нибудь глобальный Vue параметр для конкретной истории (чтобы это не затрагивало остальные) — вот был бы прям реально благодарен)

Эффективное тестирование верстки

Максим, а не поделитесь примером стека, на котором у вас все это работает? Начиная с версии ноды думаю даже. Просто предпринимаю 2-ю попытку привнести все это в наш Vue JS проект и терплю фиаско — какие-то странные проблемы возникают — банально вот сейчас не работает автоматический резолвинг расширений в импортах при сборке storybook — ну казалось бы…

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

Ну тут вполне готов поверить, но я плачу за этот террабайт хоть и не космические деньги, но верю все-таки в лояльность Яндекса к своим клиентам)

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

о, интересно — спасибо за наводку — погляжу на досуге. Но опять же дело было не только в объеме или там вложенности папок — это все не так страшно. А вот очень много маленьких файлов, кол-во которых от общего, которые надо засинкать, 80% — уверен повергнет любой бэкап софт в уныние. Не знаю как там AE этот себя ведет, но в Я.Д клиенте не поймешь толком даже прогресс чего там засинкалось, а что нет — шуршит себе чего-то, траффик генерит, а когда там процесс сойдется можно только догадываться. Отсюда и весь мой экскурс — с rsync как-то все более подконтрольно и понятно в этом плане: копирование идет последовательно по папкам с датами и можно четко видеть где мы сейчас находимся + exclude на папки с ресурсами, которые заливаем большими tar'ами. В общем, я практически уверен, что ни один удобный софт такие кейсы не покрывает — уж слишком много специфики.

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

Спасибо за интерес к статье!)

Распаковывать, думаю, нет. Т.е. процедура восстановления из бэкапа подразумевает, что я распакую это сам. Благо, восстанавливаться из бэкапов в реальной жизни приходится не так часто — я в своей практике наступал на это пару раз только, наверно, — отсюда и секрет успеха компании Acronis) iPhoto эти папки конечно же нужны — не зря ж оно их лопатит. Посему я планировал актуальность их поддерживать и как вы правильно заметили заливать каждый раз полный архив поверх. Про то, что tar из коробки умеет дифференциальные бэкапы делать — не знал — спасибо за наводку — это действительно может существенно облегчить доливки — поизучаю вопрос.

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

ну что ж снимаю шляпу: рабочий хак действительно. Но только вот, боюсь, не будет это нормально работать на моих объемах: я для пробы залинковал сейчас маленькую медиатеку на 17 Гб всего и Яндекс.Диск ушел долго и упорно синкать — внешний хард мне сейчас безболезненно не оторвать, соответственно. Напоминаю, помимо полезного объема там есть еще медиа-трэш в медиатеке, который iPhoto сам создает в процессе своей работы. И это добро, подозреваю, постоянно плодится/распухает/меняется. Это много-много маленьких файликов — на синхронизацию этого дела может уйти масса времени. Я в своих испытаниях это все засунул в один большой архив и быстренько залил в облако. Держать внешний хард подключенным к компу месяц пока там все засинкает Я.Д — не вариант. С другой стороны, проделав это раз, наверно, будет он все быстро синкать — возможно. Надо проверять — в любом случае спс за идею)

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

вот щас не понял — что это дает-то? Еще раз проблема: медиатека на внешнем харде. Не лежит она в папке Яндекс диска вообще. Мне ее надо залить в облако.

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

ну и отлично же — я просто слишком ленив, чтоб так все настраивать)

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

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

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

работает-работает, rclone этот я так понимаю много на себя берет в плане автоматизации — отсюда и проблемы. Здесь же просто WebDav шара в контексте своего аккаунта. Чем я там лью rsync или просто команды cp/mv дергаю они, по сути, даже знать не могут.

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

Да пожалуйста, но что это отменяет?) Я сильно не параною по поводу того, что фотки на внешнем облаке лежат. Мне главное бэкап и возможность доливки в него с минимальными издержками. Предложенный вами вариант подразумевает заливку каждый раз полного архива фоток я так понимаю. В моем случае это более 800 Гб и это боль.

Путь iPhoto медиатеки в облачный Яндекс.Диск через звезды и тернии

Не ну это запросто да — говорю же за 10 дней отваливался и инет, и шара. Но rsync рулит.

Диспетчер произвольных сообщений на базе google protocol buffers

Отличная статья — спасибо! Выносило мозг — не мог понять в чем задумка в protobuf в случае когда не знаешь какое сообщение тебе свалится на вход и как парсить. Теперь все встало на свои места.

Information

Rating
5,767-th
Works in
Registered
Activity