Я как-то раз решил FreeBSD 9, если не ошибаюсь установить на Pentium MMX 166 MHz. Просто лежал без дела на балконе. Неделю ядро пересобиралось. Но потом зашевелилось даже.
Прекрасная статья, спасибо за неё. Есть рецепт решения ещё одной проблемы? Как поменять команду/компанию, когда она не хочет меняться? У меня сейчас полный день сурка, потому что всем нужно объяснять буквально как дышать. Документацию писать не хотят, потому что - "это невозможно". Правильно выставлять статусы тикетов - "нет, не хочу". Пользоваться версиями - "нет, мне сложно". Любые попытки, сделать что-то правильно, разбиваются о - мне лень это делать, если хочешь можешь сделать это сам за меня. А я буду делать только то что мне интересно.
Я не понимаю, почему в каждой компании хотят переопределить роли. Есть же ISTQB. Который, как минимум описывает роли Tester, Automated Tester, Test Manager. Писать тест план и стратегию - это задача никак не рядового тестировщика. Там слишком много завязок на менеджмент, разработчиков и расписание проекта. Знать которые, вообще не компетенция рядового тестировщика. А когда на проекте тестировщик в единственном экземпляре, я ещё ни разу не видел даже вменяемых требований. А без требований вся тест стратегия и план не имеют смысла. Потому что только отталкиваясь от требований, можно сделать осознанный выбор стека инструментов, языков программирования видов и типов тестирования, тестового окружения и фикстур. Ну и построить traceability matrix. Что до SDET, то SDET как правило не занимается тестами в отличие от Automated Test Engineer. SDET занимается реализацией задач от Test Architect. Прописыванием тест фреймворка его архитектурой, разбивкой на модули, включение зависимостей. Зачастую это выливается в дополнительный уровень абстракции под конкретный продукт. Поверх базовых RestAssured/Selenium/Requests/Appium/RobotFramework etc. Реализацией моков/стабов/симуляторов. DevOps команда прикручивает пайплайны к этому всему, а автоматизаторы прописывают уже сами тест-кейсы со сценариями с или без BDD/DDT. Тогда автоматизаторы просто получают API с CRUD операциями вся логика тестов прописывается на данном уровне абстракции. А там уже легко подменяя более низкоуровневую абстракцию. Одни и те же сценарии можно использовать например как для API тестирования, так и для UI. Это если как оно работает в идеале. Ну а если, где-то начинается экономия, то соответственно пойдут и компромиссы и кому-то придется совмещать роли. Ну и времени и сил прописывать дополнительные слои абстракции - не будет.
Тестировщик - это не совсем часть разработки. Это этап между разработкой и приемной, чтобы сэкономить нервы бизнесу принимающему результат. Если заказчику, внутреннему или внешнему, показать результат первого билда напрямую от разработчиков. То скорее всего у него будет нервный тик и лёгкая паника. А вот если показать 3, 5, 10 после тестировщиков. То шансы на продление контракта и новые заказы вырастут по параболе. А вот QA - это совсем не про разработку. QA ликвидирует баги не только кучей разных методов и методик тестирования. Но он просто уничтожает их пока они даже случились. Благодаря внедрению правильных процессов, улучшению коммуникации, документации, прототипирования ну и CI/CD. До сих пор существуют компании, которые вместо использования Figma, пытаются договориться о дизайне в Excel и на пальцах. Что только делает shift left огромного количества проблем и багов. Которые легко можно было бы обсудить и отстрелить просто сделав адекватные против за пару недель.
В Южной Европе вы узнаете, что мясо далеко не самый дорогой продукт. Например рыба, которую в Архангельске за еду не считают. Может стоить в разы дороже. Например, в Греции килограмм свежевыловленной рыбы стоит от 40 евро на рынке. В таверне от 80. Мясо 8-12 евро за кило в магазине. Причем от вида мяса разница в цене на уровне погрешности. Курица, свинина, говядина, баранина. Филе курицы стоит за частую столько же или больше чем свинина, может догонять говядину. Не пытайтесь понять рассчет цен, он тут свой особенный. Никакой себестоимости, все зависит от того сколько за сегодня уже заработали. На рынке под конец, рыбу которую продавали по 25 Евро за кило с фермы, могут отдавать за 10. Овощи, салаты, зелень вообще могут бесплатно отдать, лишь бы назад не складывать и не везти. Грибы - весьма дорогой продукт, дороже мяса, особенно лесные. Свежие ягоды тоже, потому что в этом климате не растут. Греческое блюдо Гирос грамм 200 жирной свинины на вертеле, картофель фри, лук и помидор стоит дешевле чем тарелка Греческого салата. Правда и салат тут это на 2-3 человека. Оливки - тоже не самое дешевле блюдо может быть дороже мяса, фисташки, и т.д. так что да фрукты овощи - стоят почти ничего. Но также довольно много растительной пищи дороже мяса и морепродукты.
Может в Гугле все и прекрасно. Но зачастую это все разбивается о нещадную суровость бытия. Проблемы коммуникации, косяки в документации из-за чего бесконечные митинги и прочая бюрократия. Были у меня проекты и более-менее ничего. Но что-то последнее время народ вообще не понимает, что нужно хотя бы перечитать, то что ты написал, чтобы другие потом не убивались неделю. Ну и что писать вообще полезно, чтобы 25 человек потом не приходили к тебе по очереди с вопросами. А ещё неплохо бы там требования всякие набросать, архитектуру. А не переделывать это все 5 раз на месяц и доказывать, что по-другому просто не может быть.
Самая длинная пробка была на Сербско-Венгерской границе. Но там все стояли пока проверят. Вообще я так понимаю, что электромобили в новости больше для хайпа. Тут нужно понимать, что в Греции зимняя резина - отсутствует как понятие, ну по-крайней мере в Аттиках, где находиться Арахово. Те пару дней в году со снегом - просто сидят дома пока не растает. Поэтому требуют иметь цепи или аналоги, которые одевают прямо на летнюю резину. Но многие на это забивают от чего и получается большая часть проблем и пробок в снегу. Может там и встряли электрокары, но скорее всего потому что небыло цепей и они летней резиной полировали снег пока аккумулятор не сел.
Тут всё очень зависит от продукта и круга пользователей. Для международных бизнесов и сервисов можно без облаков, но тогда нужно ставить своё оборужование распределенно в мире. Требования регуляторов и для улучщения доступа. Если компания международная, но еще не уровня FAANG и не готова строить собственные датацентры, то облачные решения вполне себе выход. А соответственно и нагрузку лучше подавать из облаков. Я сейчас занимался анализом и подбором инструмента подходящего для нагрузочного тестирования. jMeter - не впечатлил наборами тестов в XML формате. Хотя, возможно, я что-то не до конца понял. K6 выбрали, так как нам нужны специфические плагины, а продукт написан на GoLang. Так что разработчики смогут помочь с плагинами. Хотя если бы не это условие, я бы остановился на Gatling. Совместная инфраструктура кода тестов и самого фреймворка - гораздо лучше в перспективе. Ну и полный доступ к библиотекам Java/Scala тоже огромный плюс. В K6 - нужно писать тесты на JS, но при этом нет поддержки Node.js, т.е. лишаешся огромного колличества библиотек. Банально для работы с файлами уже нужны сторонние библиотеки. Также не впечатляет ограничение на запуск единственного файла с тестами. Пока еще только думаю как с этим жить. Т.е. нормально разложить тетсы по файлам, чтобы не иметь простыни на кучу строк - не очень-то получается. Вроде как можно импортить файлы, но тогда не понятно как быть с тагами и как выбирать что импортировать. Пока что самый очевидный способ управлять группами тестов - это банально указывать разные файлы на уровне пайплайна, что не самое удобное решение.
Как я понимаю здесь подготавливается сообщение для чат бота со ссылками на дашборд в Grafana. Но что там будет пока не установлены переменные для Prometheus приведенные в конце статьи?
В моём случае мы сразу создали отдельные проект для K6, потому что нам нужны свои плагины, которые там и будут лежать. Ну и если нужно часто пересобирать, можно также триггерить другой проект. Он выкладывает файл в registry, а проект с тестами забирает его оттуда. Ну и можно также скачать для локальных запусков не собирая локально.
Для себя как раз наткнулся, что на Prometheus не включена опция remote-write и не могу отправить туда данные, endpoint /api/v1/write отвечает 404. Может также кому-то поможет, кто будет настраивать с нуля.
Спасибо большое за статью. Как раз сейчас настраиваю аналогичный стек. Я только не понял для чего билд самого Κ6 включать в этот же пайп-лайн? Как я понимаю это необходимо не так уж часто. Почему не положить готовый бинарник в package registry и не брать оттуда? У себя именно так и сделал. и можете немного прояснить логику репортов. На сколько я понял вначале в пайплайне создаётся сообщение для телеграм-бота. Со ссылками на Grafana, а сам собственно репортинг приведен в конце? Что нужно чтобы настроить отправку репортов в Prometheus просто установить системные переменные K6_ или еще какие-то действия?
Я думаю там вопрос не в кубике или ленте. А в том что в Виндовс такая опция вообще появилась сравнительно недавно. В линукс лет 20 уже как есть множественные рабочие столы и пространства. Еще в 7 Эйр Виндовс нужно было довольствоваться единственным рабочим столом.
Да только сетевые настройки чего стоили 19 да и лет 10 назад. Был самый рассвет pptp/l2tp, роутеры были еще не столь популярны и частенько кабель от провайдера втыкался прямо в компьютер. Вот тогда настроить это дело был еще тот квест. Также настройка только появившихся WiFi поддержки Gui Network Manager пришла очень не сразу. Патчилось ядро, твикались настройки и поднимались соединение с шифрованием через wpa-psk. Тот же Compiz - мега круто, но как часто он зависал? Alt+Ctrl+BckSpc практически такое же родовое заклинание как и Alt+Ctrl+Del для windows. А подвисающий GUI потому что виджет погоды на чудесно-красивом рабочем столе KDE, хочет обновить данные, а интернет пропал. Не знаю исправили ли сейчас. В этом конечно было много романтики и шансов почувствовать себя кулхацкером, а не рядовым виндовс юзверем. Но сколько же времени на это было потрачено. Тогда не каждую проблему можно было нагуглить и моментально получить ответ. Нужно было сидеть на форумах днями и неделями в надежде, что кто-то подскажет. Или пытаться разобраться в исходниках и тоннах конфигураций. Conki чего только стоят, до сих пор есть конфиги.
Интересно, но ради 2х диском, я бы так не заморачивался. Первый мой NAS был DLink 325. Сначала в нём умерло 2 Сигейт Барракуды, причём практически одновременно, за что я теперь их очень не люблю. Потом, пока занимался вопросами здоровья жены, и не отключил ΝΑS, прилетел CR1PT0R. А DLink просто положио на пользователей, ведь дыра была оставлена DLink в виде статичных кредов, которые они оставили для тестирования в продакшен версии прошивки. За что теперь я не люблю DLink. Но даже так идея уменьшать ёмкость в 2 раза рейдом мне не сильно нравилась и тогда я просто настроил автоматическое копирование критических данных как фотографии, фильмотеку и видео я не копировал, чтобы не забивать этим пространство. На следующий раз после шифровальщика - я купил AsusTOR 6404 потому что уже хотел миниму 4 диска. Тогда уже можно и пожертвовать 1м в пользу рейда. Тоже прилетал какой-то шифровальщик, но мне в этот раз повезло, NAS был выключен и я закончил игры с выбрасынием доступа к нему. Теперь только доступ в локальную сеть через VPN. Ну и поддержка BTRFS тоже радует. Единственное, что не радует политика всех вендоров против KODI(XBMC). Это был один из аргументов покупки данного вендора, но потом поддержку KODI выпилили с кривой аргументацией по настоянию правообладателей контента, якобы KODI активно используется в пиратстве. Я же подозреваю, что по настоянию Plex, чтобы ничего бесплатного людям не давать и подсаживать на подписки. В общем ΤrueNAS - определённо плюс к безопасности и управлению. Но зачем мастерить стоечный NAS аж на 2 диска - я не очень понял.
Проблем много, но как идея мне в голову приходило какое-то время назад, когда стали убирать зарядки из комплектации телефонов. Я так призадумался сколько же стоит выпрямителей напряжения в нашей любимой электроники. И сколько же их можно было бы выкинуть, если бы в доме была сеть 12 вольт. Только опять незадача. Куча электроники хочет кучу разных напряжений, 3.3, 5, 12, 24, И это только в одном компьютере. А так еще бывают всякие 15 и 20 Вольт. Это все здорово, но какую же работу по стандартизации придётся сперва проделать, чтобы сократить этот зоопарк. И тут возникает вопрос курицы и яйца - а стоит ли игра свеч.
Ну не знаю, меня в школе приучили, что надо выбирать не просто справочник автора какого-то, а от конкретного издателя и конкретное издание с исправлениями, чтобы не парится по ошибкам. Учебники физики и математики новые массово стали печатать в 90х. Мы получали прям список какие нельзя использовать, хотя и новая программа школьная их рекомендовала. Учителя сказали, что это фуфло редкое, поэтому берите старые советские автор такой-то, издательство, год, и т.д. В университете было то же самое. Справочник по частным характеристикам транзисторов. Даже говорили в какой из университетских библиотек он лежит и сколько там экземпляров. Так что, я пожалуй не вижу ничего странного в том что нужно понимать что за книга и какой можно доверять.
Лет 12 пользовался Sony SVS 15". Сестре двоюродной посоветовал и купили SVS 13". На то время 2012 год, это была прям революция. 15 дюймов в 2 кг, и 13 - около 1,5. Ремонтопригодность - прямо скажу была весьма плохой. Для чистки требовалось разобрать полностью, а не просто снять нижнюю крышку, потому как система охлаждения была на другой стороне платы. В остальном - одни плюсы. Док станция со встроенным дополнительным диском - тоже просто супер. Зарядка всегда в рюкзаке или в другом месте, дома можно от док-станции заряжаться. Для тех кому больше автономности и не критичен вес, допустим аккумулятор нашлёпывался на днище, где есть специальный разъём для него. Тогда 15" превращались в порядка 2,8 кг как и остальные на рынке, но с автономной часов 7. Клавиатура - прелесть. стрелки хоть немного уменьшенные, но не слеплены в 1 ряд. Огромный по тому времени тач-пэд с поддержкой круговой прокрутки, которую нехорошие люди, сломали после Windows 7. До сих пор лежит. Чистил его и апгрейдил по мелочи, SSD, и память. Поскольку один слот распаян на плате в виде 4ГБ, максимально было 12 ГБ. Проц не менял, там и так стоял i7. Сейчас перешёл на Asus Pro Art 16. Те же 2 кг, и металлический корпус, намного больше мощи. Ryzen 7 и 32 ГБ памяти с апгрейдом до 64. Круговой прокрутки нет на тачпаде. Но зато есть прокрутка на физической крутилке. Жене взял ZenBook - 1,3 кг на 14 дюймов. Считаю Asus сейчас топ. Да, я как раз за OLED экраны. Кому не нравиться есть варианты без них.
Зачем Вы читаете, если Вам это тяжело? Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать? И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять. Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен? Только долго ли на такое будут закрывать глаза?
Мир изменился. Я чувствую это по воде. (с) Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc. Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик. Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное. Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает. Мышление тестировщика: один раз не сработало - значит не работает. И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна. Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности. Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Ну вот поэтому, продукты берут и выкидывают, а потом переписывают с нуля, потому что разобраться в таком легаси - дороже выйдет. Хотя в принципе это тоже вполне рабочий вариант. Если бизнес на таком продукте отбил вложения и даже заработал, то почему нет?
Я как-то раз решил FreeBSD 9, если не ошибаюсь установить на Pentium MMX 166 MHz. Просто лежал без дела на балконе. Неделю ядро пересобиралось. Но потом зашевелилось даже.
Прекрасная статья, спасибо за неё.
Есть рецепт решения ещё одной проблемы?
Как поменять команду/компанию, когда она не хочет меняться?
У меня сейчас полный день сурка, потому что всем нужно объяснять буквально как дышать.
Документацию писать не хотят, потому что - "это невозможно".
Правильно выставлять статусы тикетов - "нет, не хочу".
Пользоваться версиями - "нет, мне сложно".
Любые попытки, сделать что-то правильно, разбиваются о - мне лень это делать, если хочешь можешь сделать это сам за меня. А я буду делать только то что мне интересно.
Я не понимаю, почему в каждой компании хотят переопределить роли. Есть же ISTQB. Который, как минимум описывает роли Tester, Automated Tester, Test Manager.
Писать тест план и стратегию - это задача никак не рядового тестировщика. Там слишком много завязок на менеджмент, разработчиков и расписание проекта. Знать которые, вообще не компетенция рядового тестировщика. А когда на проекте тестировщик в единственном экземпляре, я ещё ни разу не видел даже вменяемых требований. А без требований вся тест стратегия и план не имеют смысла. Потому что только отталкиваясь от требований, можно сделать осознанный выбор стека инструментов, языков программирования видов и типов тестирования, тестового окружения и фикстур. Ну и построить traceability matrix.
Что до SDET, то SDET как правило не занимается тестами в отличие от Automated Test Engineer. SDET занимается реализацией задач от Test Architect. Прописыванием тест фреймворка его архитектурой, разбивкой на модули, включение зависимостей. Зачастую это выливается в дополнительный уровень абстракции под конкретный продукт. Поверх базовых RestAssured/Selenium/Requests/Appium/RobotFramework etc. Реализацией моков/стабов/симуляторов. DevOps команда прикручивает пайплайны к этому всему, а автоматизаторы прописывают уже сами тест-кейсы со сценариями с или без BDD/DDT.
Тогда автоматизаторы просто получают API с CRUD операциями вся логика тестов прописывается на данном уровне абстракции. А там уже легко подменяя более низкоуровневую абстракцию. Одни и те же сценарии можно использовать например как для API тестирования, так и для UI.
Это если как оно работает в идеале. Ну а если, где-то начинается экономия, то соответственно пойдут и компромиссы и кому-то придется совмещать роли. Ну и времени и сил прописывать дополнительные слои абстракции - не будет.
Тестировщик - это не совсем часть разработки. Это этап между разработкой и приемной, чтобы сэкономить нервы бизнесу принимающему результат. Если заказчику, внутреннему или внешнему, показать результат первого билда напрямую от разработчиков. То скорее всего у него будет нервный тик и лёгкая паника. А вот если показать 3, 5, 10 после тестировщиков. То шансы на продление контракта и новые заказы вырастут по параболе.
А вот QA - это совсем не про разработку. QA ликвидирует баги не только кучей разных методов и методик тестирования. Но он просто уничтожает их пока они даже случились. Благодаря внедрению правильных процессов, улучшению коммуникации, документации, прототипирования ну и CI/CD.
До сих пор существуют компании, которые вместо использования Figma, пытаются договориться о дизайне в Excel и на пальцах.
Что только делает shift left огромного количества проблем и багов. Которые легко можно было бы обсудить и отстрелить просто сделав адекватные против за пару недель.
В Южной Европе вы узнаете, что мясо далеко не самый дорогой продукт.
Например рыба, которую в Архангельске за еду не считают. Может стоить в разы дороже. Например, в Греции килограмм свежевыловленной рыбы стоит от 40 евро на рынке. В таверне от 80. Мясо 8-12 евро за кило в магазине. Причем от вида мяса разница в цене на уровне погрешности. Курица, свинина, говядина, баранина. Филе курицы стоит за частую столько же или больше чем свинина, может догонять говядину. Не пытайтесь понять рассчет цен, он тут свой особенный. Никакой себестоимости, все зависит от того сколько за сегодня уже заработали. На рынке под конец, рыбу которую продавали по 25 Евро за кило с фермы, могут отдавать за 10. Овощи, салаты, зелень вообще могут бесплатно отдать, лишь бы назад не складывать и не везти.
Грибы - весьма дорогой продукт, дороже мяса, особенно лесные. Свежие ягоды тоже, потому что в этом климате не растут.
Греческое блюдо Гирос грамм 200 жирной свинины на вертеле, картофель фри, лук и помидор стоит дешевле чем тарелка Греческого салата. Правда и салат тут это на 2-3 человека.
Оливки - тоже не самое дешевле блюдо может быть дороже мяса, фисташки, и т.д. так что да фрукты овощи - стоят почти ничего. Но также довольно много растительной пищи дороже мяса и морепродукты.
Может в Гугле все и прекрасно. Но зачастую это все разбивается о нещадную суровость бытия.
Проблемы коммуникации, косяки в документации из-за чего бесконечные митинги и прочая бюрократия. Были у меня проекты и более-менее ничего. Но что-то последнее время народ вообще не понимает, что нужно хотя бы перечитать, то что ты написал, чтобы другие потом не убивались неделю. Ну и что писать вообще полезно, чтобы 25 человек потом не приходили к тебе по очереди с вопросами. А ещё неплохо бы там требования всякие набросать, архитектуру. А не переделывать это все 5 раз на месяц и доказывать, что по-другому просто не может быть.
Самая длинная пробка была на Сербско-Венгерской границе. Но там все стояли пока проверят.
Вообще я так понимаю, что электромобили в новости больше для хайпа. Тут нужно понимать, что в Греции зимняя резина - отсутствует как понятие, ну по-крайней мере в Аттиках, где находиться Арахово. Те пару дней в году со снегом - просто сидят дома пока не растает. Поэтому требуют иметь цепи или аналоги, которые одевают прямо на летнюю резину. Но многие на это забивают от чего и получается большая часть проблем и пробок в снегу. Может там и встряли электрокары, но скорее всего потому что небыло цепей и они летней резиной полировали снег пока аккумулятор не сел.
Проехал неделю назад на электрокаре из Афин в Гданьск 2500 км. Что я делаю не так?
Тут всё очень зависит от продукта и круга пользователей. Для международных бизнесов и сервисов можно без облаков, но тогда нужно ставить своё оборужование распределенно в мире. Требования регуляторов и для улучщения доступа. Если компания международная, но еще не уровня FAANG и не готова строить собственные датацентры, то облачные решения вполне себе выход. А соответственно и нагрузку лучше подавать из облаков.
Я сейчас занимался анализом и подбором инструмента подходящего для нагрузочного тестирования.
jMeter - не впечатлил наборами тестов в XML формате. Хотя, возможно, я что-то не до конца понял. K6 выбрали, так как нам нужны специфические плагины, а продукт написан на GoLang. Так что разработчики смогут помочь с плагинами.
Хотя если бы не это условие, я бы остановился на Gatling. Совместная инфраструктура кода тестов и самого фреймворка - гораздо лучше в перспективе. Ну и полный доступ к библиотекам Java/Scala тоже огромный плюс.
В K6 - нужно писать тесты на JS, но при этом нет поддержки Node.js, т.е. лишаешся огромного колличества библиотек. Банально для работы с файлами уже нужны сторонние библиотеки.
Также не впечатляет ограничение на запуск единственного файла с тестами. Пока еще только думаю как с этим жить. Т.е. нормально разложить тетсы по файлам, чтобы не иметь простыни на кучу строк - не очень-то получается. Вроде как можно импортить файлы, но тогда не понятно как быть с тагами и как выбирать что импортировать.
Пока что самый очевидный способ управлять группами тестов - это банально указывать разные файлы на уровне пайплайна, что не самое удобное решение.
Я имею ввиду часть:
Как я понимаю здесь подготавливается сообщение для чат бота со ссылками на дашборд в Grafana. Но что там будет пока не установлены переменные для Prometheus приведенные в конце статьи?
В моём случае мы сразу создали отдельные проект для K6, потому что нам нужны свои плагины, которые там и будут лежать. Ну и если нужно часто пересобирать, можно также триггерить другой проект. Он выкладывает файл в registry, а проект с тестами забирает его оттуда. Ну и можно также скачать для локальных запусков не собирая локально.
Для себя как раз наткнулся, что на Prometheus не включена опция remote-write и не могу отправить туда данные, endpoint /api/v1/write отвечает 404. Может также кому-то поможет, кто будет настраивать с нуля.
Спасибо большое за статью. Как раз сейчас настраиваю аналогичный стек. Я только не понял для чего билд самого Κ6 включать в этот же пайп-лайн? Как я понимаю это необходимо не так уж часто. Почему не положить готовый бинарник в package registry и не брать оттуда? У себя именно так и сделал.
и можете немного прояснить логику репортов.
На сколько я понял вначале в пайплайне создаётся сообщение для телеграм-бота. Со ссылками на Grafana, а сам собственно репортинг приведен в конце?
Что нужно чтобы настроить отправку репортов в Prometheus просто установить системные переменные K6_ или еще какие-то действия?
Я думаю там вопрос не в кубике или ленте. А в том что в Виндовс такая опция вообще появилась сравнительно недавно. В линукс лет 20 уже как есть множественные рабочие столы и пространства. Еще в 7 Эйр Виндовс нужно было довольствоваться единственным рабочим столом.
Да только сетевые настройки чего стоили 19 да и лет 10 назад. Был самый рассвет pptp/l2tp, роутеры были еще не столь популярны и частенько кабель от провайдера втыкался прямо в компьютер. Вот тогда настроить это дело был еще тот квест. Также настройка только появившихся WiFi поддержки Gui Network Manager пришла очень не сразу. Патчилось ядро, твикались настройки и поднимались соединение с шифрованием через wpa-psk.
Тот же Compiz - мега круто, но как часто он зависал? Alt+Ctrl+BckSpc практически такое же родовое заклинание как и Alt+Ctrl+Del для windows.
А подвисающий GUI потому что виджет погоды на чудесно-красивом рабочем столе KDE, хочет обновить данные, а интернет пропал. Не знаю исправили ли сейчас.
В этом конечно было много романтики и шансов почувствовать себя кулхацкером, а не рядовым виндовс юзверем. Но сколько же времени на это было потрачено. Тогда не каждую проблему можно было нагуглить и моментально получить ответ. Нужно было сидеть на форумах днями и неделями в надежде, что кто-то подскажет. Или пытаться разобраться в исходниках и тоннах конфигураций. Conki чего только стоят, до сих пор есть конфиги.
Интересно, но ради 2х диском, я бы так не заморачивался. Первый мой NAS был DLink 325. Сначала в нём умерло 2 Сигейт Барракуды, причём практически одновременно, за что я теперь их очень не люблю. Потом, пока занимался вопросами здоровья жены, и не отключил ΝΑS, прилетел CR1PT0R. А DLink просто положио на пользователей, ведь дыра была оставлена DLink в виде статичных кредов, которые они оставили для тестирования в продакшен версии прошивки. За что теперь я не люблю DLink. Но даже так идея уменьшать ёмкость в 2 раза рейдом мне не сильно нравилась и тогда я просто настроил автоматическое копирование критических данных как фотографии, фильмотеку и видео я не копировал, чтобы не забивать этим пространство. На следующий раз после шифровальщика - я купил AsusTOR 6404 потому что уже хотел миниму 4 диска. Тогда уже можно и пожертвовать 1м в пользу рейда. Тоже прилетал какой-то шифровальщик, но мне в этот раз повезло, NAS был выключен и я закончил игры с выбрасынием доступа к нему. Теперь только доступ в локальную сеть через VPN. Ну и поддержка BTRFS тоже радует. Единственное, что не радует политика всех вендоров против KODI(XBMC). Это был один из аргументов покупки данного вендора, но потом поддержку KODI выпилили с кривой аргументацией по настоянию правообладателей контента, якобы KODI активно используется в пиратстве. Я же подозреваю, что по настоянию Plex, чтобы ничего бесплатного людям не давать и подсаживать на подписки.
В общем ΤrueNAS - определённо плюс к безопасности и управлению. Но зачем мастерить стоечный NAS аж на 2 диска - я не очень понял.
Проблем много, но как идея мне в голову приходило какое-то время назад, когда стали убирать зарядки из комплектации телефонов. Я так призадумался сколько же стоит выпрямителей напряжения в нашей любимой электроники. И сколько же их можно было бы выкинуть, если бы в доме была сеть 12 вольт. Только опять незадача. Куча электроники хочет кучу разных напряжений, 3.3, 5, 12, 24, И это только в одном компьютере. А так еще бывают всякие 15 и 20 Вольт.
Это все здорово, но какую же работу по стандартизации придётся сперва проделать, чтобы сократить этот зоопарк. И тут возникает вопрос курицы и яйца - а стоит ли игра свеч.
Ну не знаю, меня в школе приучили, что надо выбирать не просто справочник автора какого-то, а от конкретного издателя и конкретное издание с исправлениями, чтобы не парится по ошибкам. Учебники физики и математики новые массово стали печатать в 90х. Мы получали прям список какие нельзя использовать, хотя и новая программа школьная их рекомендовала. Учителя сказали, что это фуфло редкое, поэтому берите старые советские автор такой-то, издательство, год, и т.д.
В университете было то же самое. Справочник по частным характеристикам транзисторов. Даже говорили в какой из университетских библиотек он лежит и сколько там экземпляров.
Так что, я пожалуй не вижу ничего странного в том что нужно понимать что за книга и какой можно доверять.
Лет 12 пользовался Sony SVS 15".
Сестре двоюродной посоветовал и купили SVS 13". На то время 2012 год, это была прям революция. 15 дюймов в 2 кг, и 13 - около 1,5.
Ремонтопригодность - прямо скажу была весьма плохой. Для чистки требовалось разобрать полностью, а не просто снять нижнюю крышку, потому как система охлаждения была на другой стороне платы.
В остальном - одни плюсы. Док станция со встроенным дополнительным диском - тоже просто супер. Зарядка всегда в рюкзаке или в другом месте, дома можно от док-станции заряжаться. Для тех кому больше автономности и не критичен вес, допустим аккумулятор нашлёпывался на днище, где есть специальный разъём для него. Тогда 15" превращались в порядка 2,8 кг как и остальные на рынке, но с автономной часов 7.
Клавиатура - прелесть. стрелки хоть немного уменьшенные, но не слеплены в 1 ряд. Огромный по тому времени тач-пэд с поддержкой круговой прокрутки, которую нехорошие люди, сломали после Windows 7.
До сих пор лежит. Чистил его и апгрейдил по мелочи, SSD, и память. Поскольку один слот распаян на плате в виде 4ГБ, максимально было 12 ГБ. Проц не менял, там и так стоял i7.
Сейчас перешёл на Asus Pro Art 16. Те же 2 кг, и металлический корпус, намного больше мощи. Ryzen 7 и 32 ГБ памяти с апгрейдом до 64.
Круговой прокрутки нет на тачпаде. Но зато есть прокрутка на физической крутилке.
Жене взял ZenBook - 1,3 кг на 14 дюймов. Считаю Asus сейчас топ. Да, я как раз за OLED экраны. Кому не нравиться есть варианты без них.
Зачем Вы читаете, если Вам это тяжело?
Откуда вы выдумали 95% случаев? Это исключительно ваш, очень узкий опыт. Зачем его экстраполировать?
И да программистов, которые задают вопросы зачем нужны архитекторы и саботируют работу - стоит увольнять.
Потому что, компетентный инженер, сам напишет необходимую архитектуру(блок-схему алгоритма, машину состояний- диаграмму классов и т.д.), а не будет задавать вопросы, кто такой архитектор и зачем он нужен. Можно еще так же поспрашивать, кто такой менеджер и зачем он нужен? Что такое бизнес и зачем он нужен?
Только долго ли на такое будут закрывать глаза?
Мир изменился. Я чувствую это по воде. (с)
Просто всё больше и больше мир зависит от программных продуктов. А как следствие - продукты усложняется. Из этого же вытекает, что команда разработки - это уже не просто разработчик и тестировщик. Есть Software Development Engineer, Software Development Engineer in Testing, QA Engineer, Business Analytic, Product Owner, Project Manager, Test Manager, Software Architector, Test Architector, Solution Architector, Electronic Engineers, Mechanic Engineer, HW Test Engineer, System Test Engineer, DevOps Engineer, DevSecOps Engineer etc.
Тут уже не так просто провести линию и сказать кто из этих ролей тестировщик, а кто разработчик.
Но концептуально, эти роли нельзя смешивать, потому как мышление противоположное.
Из своего опыта я видел только такие случаи. Мышление разработчика: один раз сработало - значит работает.
Мышление тестировщика: один раз не сработало - значит не работает.
И так и должно быть, а потом уже возникает коммуникация и в этом споре рождается истинна.
Вероятно существуют разработчики, знакомые с всевозможными пирамидами тестирования, всеми видами и типами тестирования, а также владеющими всеми методиками. Но, лично мне такие не попадались. Максимум, что я видел, они создали очень много различных тестов. Но когда, подходит вопрос, а какие тесты собственно нужно запускать и в каких случаях. Самый частый ответ - все и всегда. И вот тут как раз и приходят на помощь pair wise таблицы, граничные значения, классы эквивалентности, распределение quality gates, построение пирамиды под продукт, а не просто взять из книги/интернета, определение какие виды тестирования закрыть самим, а где подключить подрядчиков ну и Test Plans соответственно. И чтобы всё это подгадать к нужному релизу. Ну и время тест рана не стремилось к бесконечности.
Плюс до сих пор не осел туман войны Agile universal team VS Universal Engineer. Уж очень последнего хочется бизнесу, чтобы не разбираться во всех ролях перечисленных вначале, ну и чтобы не нужно было каждого из них хотя бы по 2, чтобы и в отпуск можно было сходить, а работа не встала, ну и ревьювить результат кто-то должен.
Ну вот поэтому, продукты берут и выкидывают, а потом переписывают с нуля, потому что разобраться в таком легаси - дороже выйдет.
Хотя в принципе это тоже вполне рабочий вариант. Если бизнес на таком продукте отбил вложения и даже заработал, то почему нет?