Пользователь
Мы собрали митап, где трое экспертов по QA рассказали, о чем тестировщику нужно говорить с командой разработки, какими инструментами пользоваться для планирования и тестирования, а также что нужно учесть, чтобы сделать сайты безопасными. Внутри есть видео и текстовая выжимка по каждому докладу.
Технология eXpress Data Path (XDP) позволяет выполнить произвольную обработку трафика на интерфейсах Linux до того, как пакеты поступят в сетевой стек ядра. Применение XDP — защита от DDoS-атак (CloudFlare), сложные фильтры, сбор статистики (Netflix). Программы XDP исполняются виртуальной машиной eBPF, поэтому имеют ограничения как на свой код, так и на доступные функции ядра в зависимости от типа фильтра.
Статья призвана восполнить недостатки многочисленных материалов по XDP. Во-первых, в них дается готовый код, который сразу обходит особенности XDP: подготовлен для верификации или слишком прост, чтобы вызвать проблемы. При попытке потом написать свой код с нуля нет понимания, что делать с характерными ошибками. Во-вторых, не освещаются способы локально тестировать XDP без ВМ и «железа», при том, что у них свои «подводные камни». Текст рассчитан на программистов, знакомых с сетями и Linux, которым интересен XDP и eBPF.
ip link help.
Сегодня поговорим о создании UI smoke-теста для сайта с использованием фреймворков Cucumber и Selenide. Статья рассчитана на junior, который совсем ничего не знает про данные фреймворки. Опытный junior найдет во второй части интересные моменты, до которых я доходил пару месяцев.
Статья состоит из двух частей:
Selenide – фреймворк (а точнее библиотека), обертывающий Selenium. Чем он отличается, прекрасно описано автором, Андреем Солнцевым. Главное отличие – Selenide позволяет сократить кучу строчек кода при написании UI тестов, что является одной из главных задач при создании тестов/написании кода, ибо Вы должны заботиться о том тестере, который придет после Вас и должен будет разбирать Ваше творение.
Cucumber – это фреймворк, реализующий подход BDD/TDD.
Просматривая статьи по проектированию ПО, я постоянно встречал тучу невиданных сокращений и вскользь упоминаемых практик разработки.
Подходы к разработке делятся по сложности, областям применения и целям.
Думаю, настало время разобраться, зачем же они нужны, почему их так много, и как они могут быть нам полезны.
Мы начнем знакомиться с ними от самых простых до довольно сложных, рассмотрим примеры использования и плюсы и минусы каждого из них.
На Хабре уже долгое время публикуется совместный перевод (у которого ещё есть отдельный сайт авторства MagisterLudi) замечательной книги Ричарда Хэмминга "The Art of Doing Science and Engineering". Я долгое время хотел её прочитать в оригинале. Да не просто прочитать, а составить насколько возможно краткую выжимку основных идей каждой главы. И вот недавно мне удалось это сделать.
Целью самой книги является "подготовить вас к вашему техническому будущему" путём обучения "стилю" мышления. Поэтому извлечённые идеи в основном имеют достаточно общий характер. Также из-за частого способа передачи идеи в виде историй некоторые пункты статьи являются моей личной их интерпретацией.
Из-за достаточно большого количества материала и его "плотной" подачи данная статья всё равно получилась достаточно объёмной. Поэтому предлагаю её TL;DR.
«Цель этого курса — подготовить вас к вашему техническому будущему.»
Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2588 в закладки, 429k прочтений)?