• Как называется этот эффект в поле ввода?

    hahenty
    @hahenty
    ('•')
    Ответ написан
    Комментировать
  • Что такое slug в разработке?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Чаще всего, как уже написали, встречается в URL, но все же его значение чуть более шире - slug это уникальная строка идентификатор, понятная человеку (в отличие от ID) и содержащая только "безопасные" символы:
    - 0-9
    - a-z (общепринято - в нижнем регистре)
    - символ -
    - иногда еще символ _
    Могут использоваться не только в URL для понятности, но и, например, в запросах к БД (в первую очередь - на уровне АПИ) - ведь
    SELECT * FROM pages WHERE category="some-slug"
    более понятно, чем
    SELECT * FROM pages WHERE category=126.
    На уровне API это выглядит как
    get_pages_in_category( 'some-slug' )
    или
    $object->get_pages_in_category( 'some-slug' ).
    В общем, это человеко-понятный уникальный идентификатор.
    Ответ написан
    1 комментарий
  • Как осуществить переход кнопкой "Полная версия сайта" на мобильном устройстве?

    @IceJOKER
    Web/Android developer
    зачем, если сайт полностью адаптивный?
    А если все же нужно - создаете копию старого css, убираете весь код связанный с адаптивностью(всякие медиа запросы) и сохраняете как desktop.css , а в мобильной версии даете ссылку переходя по которой css файл меняется.
    /?set_theme=desktop

    if($_GET['set_theme'] == 'desktop'){
      //устанавливаете desktop.css и сохраняете в сессии
    }
    Ответ написан
    Комментировать
  • Как обойти систему верификации при автоматизированной регистрации аккаунта?

    @Arlekcangp
    Разработчик, Лид, Архитектор ПО
    можно также автоматически заходить на указанную почту, в которую пришло письмо с кодом, парсить его оттуда и вставлять в поле при регистрации

    Это имеет смысл делать, если тестируете саму регистрацию. В других тестах есть несколько вариантов в зависимости от того где и на какой базе происходит прогон тестов (очевидно, это функциональные или интеграционные тесты, раз речь идёт о сторонней почте) Если тесты прогоняются на игрушечной базе, пустой базе или каком-то стэйдж, который достаточно закрыт от внешнего мира, то вы можете деплоить туда доп. модуль, который будет содержать апи регистрации без проверки кода из почты. На продакшен этот модуль деплоиться не будет и он должен быть сделан так, что бы безболезненно отрезаться от приложения не нарушая его функционал (и естественно с учётом требований безопасности) Разумеется, это только для тестов, которые саму по себе регистрацию не проверяют, но для них необходим свежий зарегистрированный пользователь.
    Если же тесты гоняются на проде, то очевидно этот способ не подходит и остаётся либо заранее зарегистрированный пользователь всегда один и тот же. Либо каждый раз регистрировать ящик и потом его проверять.
    Ответ написан
    Комментировать
  • Как обойти систему верификации при автоматизированной регистрации аккаунта?

    @RickStead
    pymailtm вам в помощь

    account = pymailtm.MailTm()
        def get_one_message():
            while True:
                print("\nWaiting for new messages...")
                start = len(account.get_messages())
                while len(account.get_messages()) == start:
                    sleep(1)
                print("New message arrived!")
                last_message = account.get_messages()[0].text
                break
         print(last_message)


    Из минусов только "одноразовость" почты, получить повторный доступ можно только в течении короткого времени (~ 1 день)
    Ответ написан
    1 комментарий
  • Какой язык выбрать для автоматизированного тестирования?

    @Arlekcangp
    Разработчик, Лид, Архитектор ПО
    Я бы спросил у самих разработчиков, хотят они помогать или это им не надо. С моей точки зрения команда должна быть тесно интегрирована и разработчики сами должны быть заинтересованы в качественных тестах и в их читаемости. И тут язык имеет значение. Разработчики должны понимать тест и в некоторых случаях даже советовать как его улучшить, потому что им всяко виднее как их код работает и где может зафэйлиться. Если же разработчики говорят "отстань со своими тестами" или "У нас некому работать 'обезъяной', поэтому нам важнее что бы ты дальше тыкал руками", то это очевидные организационные проблемы и их нужно решать не выбором языка, а поднятием этого вопроса на уровень руководства.
    Ответ написан
    Комментировать
  • Какой язык выбрать для автоматизированного тестирования?

    @Kirill-Gorelov
    С ума с IT
    Дайтие пожалуйста толковый ответ,

    Учи несколько инструментов. И JS и python, и java все они отлично подходят для "тестировки".
    Ответ написан
    Комментировать
  • Какой язык выбрать для автоматизированного тестирования?

    @taktik
    Sr. QA automation | SDET
    На самом деле совет выбирать тот язык, на котором пишет команда - ни разу себя не оправдал. Тестировщики все равно не получают никакой помощи от разработчиков и вынуждены делать все сами.

    Поэтому имеет смысл выбирать тот язык, который имеет самый низкий порог вхождения и высокую популярность в автоматизации. И тут лучший выбор наверное - Python
    Ответ написан
    1 комментарий
  • С чего начать изучение автоматизации тестирования?

    @taktik
    Sr. QA automation | SDET
    На этот вопрос нельзя ответить просто. Объем того, что нужно изучить зависит от специфики проекта. Если проект представляет собой сайт с серверным рендерингом или SPA с rest-бэкендом, то это один путь со своим набором технологий. Если десктопное или мобильное приложение - другой путь с другим набором технологий.

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

    Допустим ваш проект - это SPA с rest-бэкендом, значит интеграционный слой пирамиды тестирования можно закрыть api-тестами, а end-to-end слой - UI тестами. Но тут тоже не все так просто, api-тесты могут запускаться на отдельно поднятом сервисе с замоканным окружением, а могут запускаться для сервиса развернутого в тестовой ифраструктуре.

    В общем случае можно посоветовать следующее:
    1) Изучайте один из популярных языков, лучше всего Python, он наиболее универсальный и имеет низкий порог вхождения
    2) Начинайте с автоматизации api уровня
    3) Если на проекте есть CI/CD пайплайн, сразу интегрируйте тесты в него, пусть запускаются как отдельный стейдж
    4) Настройте отправку сообщений о прохождении тестов в корпоративный месседжер. Очень важно, чтобы о тестах знала вся команда, а не только тестировщики
    5) Для UI тестов используйте Selene - это удобная обертка поверх selenium
    5) Не пишите много UI тестов. Достаточно небольшого количества покрывающих основные пользовательские сценарии

    Но я очень сомневаюсь, что джун осилит это все. Поговорите с руководством и пусть наймут опытного автоматизатора, если есть реальная потребность.
    Ответ написан
    1 комментарий
  • С чего начать изучение автоматизации тестирования?

    @bbrother92
    Я бы начал с изучения JS, далее cypress - фреймворк для автоматизации, думаю там не сложно, можно на гитхабе примеры готовые поискать, далее это все запустить на jenkins чтобы тесты какой нибудь веб страницы гонялись по расписанию. Еще как вариант api тесты написать https://codecept.io/api/ используя вот это.
    Ответ написан
    Комментировать
  • Заблокировали аккаунт на UTest.com?

    @lonuel77
    имхо вместо впн надежнее арендовать виртуальный сервер в другой стране и открывать их сайт на сервере, подробнее clck.ru/rfeiR
    Ответ написан
    Комментировать
  • Где взять тест-кейсы для тренировки скила qa автоматизатора?

    @Araya
    Что значит где взять? Написать самому конечно же.
    Ответ написан
    4 комментария
  • Какой сброс будет лучше для css?

    valgerofficial
    @valgerofficial
    Вот так

    *,
    ::before,
    ::after {
        padding: 0;
        margin: 0;
    
        -webkit-box-sizing: border-box;
           -moz-box-sizing: border-box;
             -o-box-sizing: border-box;
                box-sizing: border-box;
    }
    
    html {
        -webkit-text-size-adjust: 100%;
        -ms-text-size-adjust: 100%;
        -webkit-font-smoothing: subpixel-antialiased;
        text-rendering: geometricPrecision;
    }
    
    body {
        margin: 0;
        padding: 0;
        font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Ubuntu, Helvetica Neue, sans-serif;
    
        -webkit-font-smoothing: subpixel-antialiased;
        -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
        -webkit-touch-callout: none;
    }
    
    html,
    body {
        height: 100%;
        min-height: 100%;
        font-feature-settings: kern 1, liga 1, calt 1, pnum 1, tnum 0, onum 1, lnum 0, dlig 0;
    }
    
    html,
    body,
    article,
    aside,
    details,
    figcaption,
    figure,
    footer,
    header,
    hgroup,
    main,
    menu,
    nav,
    section,
    summary {
        display: block;
    }
    
    h1,
    h2,
    h3,
    h4,
    h5,
    h6 {font-weight: 400;}
    
    h1  {font-size: 2.2em;}
    h2  {font-size: 1.9em;}
    h3  {font-size: 1.65em;}
    h4  {font-size: 1.4em;}
    h5  {font-size: 1.2em;}
    h6  {font-size: 1em;}
    
    audio:not([controls]) {
        display: none;
        height: 0;
    }
    
    [hidden],
    template {
        display: none;
    }
    
    a {
        background: transparent;
        text-decoration: none;
        cursor: pointer;
    }
    
    a:active,
    a:hover {
        outline: 0;
    }
    
    img {
        border: 0;
    }
    
    ul,
    li {
        outline: 0;
        border: 0;
        list-style: none;
    }
    
    abbr {
        cursor: help;
        font-feature-settings: kern 1, liga 1, calt 1, pnum 1, tnum 0, onum 1, lnum 0, smcp 1, c2sc 1;
    }
    
    abbr[title] {
        text-decoration: none;
        border-bottom: 1px dotted;
    }
    
    b,
    strong {
        font-weight: 700;
    }
    
    dfn {
        font-style: italic;
    }
    
    mark {
        background: #ff0;
        color: #000;
    }
    
    time {
        font-feature-settings: kern 1, liga 1, calt 1, pnum 1, tnum 0, onum 1, lnum 0;
    }
    
    small {
        font-weight: 400;
        font-size: 80%;
    }
    
    sub,
    sup {
        font-size: 75%;
        line-height: 0;
        position: relative;
        vertical-align: baseline;
    }
    
    sup {
        top: -0.5em;
        font-feature-settings: kern 1, liga 1, calt 1, pnum 1, tnum 0, onum 1, lnum 0, dlig 0, sups 1;
    }
    
    sub {
        bottom: -0.25em;
        font-feature-settings: kern 1, liga 1, calt 1, pnum 1, tnum 0, onum 1, lnum 0, dlig 0, subs 1;
    }
    
    svg:not(:root) {
        overflow: hidden;
    }
    
    hr {
        height: 0;
        -webkit-box-sizing: content-box;
        -moz-box-sizing: content-box;
        box-sizing: content-box;
    }
    
    pre {
        overflow: auto;
    }
    
    code,
    kbd,
    pre,
    samp {
        font-family: "Source Code Pro", Consolas", "Courier New", SFMono-Regular, Menlo, Monaco, monospace;
        font-size: 0.8em;
        font-feature-settings: kern 0, liga 0, calt 1, dlig 0, pnum 0, tnum 1, onum 0, lnum 1, zero 1;
    }
    
    button,
    form,
    input,
    optgroup,
    select,
    textarea {
        outline: 0;
        color: inherit;
        font: inherit;
    }
    
    button,
    select {
        border: 0;
        text-transform: none;
    }
    
    button,
    html input[type="button"],
    input[type="reset"],
    input[type="submit"] {
        -webkit-appearance: button;
        cursor: pointer;
    }
    
    button:not(:disabled),
    [type="button"]:not(:disabled),
    [type="reset"]:not(:disabled),
    [type="submit"]:not(:disabled) {
      cursor: pointer;
    }
    
    button[disabled],
    html input[disabled] {
        cursor: default;
    }
    
    button::-moz-focus-inner,
    input::-moz-focus-inner {
        border: 0;
    }
    
    input {
        line-height: normal;
    }
    
    input[type="radio"],
    input[type="checkbox"] {
        box-sizing: border-box;
        padding: 0;
    }
    
    input[type="number"]::-webkit-inner-spin-button,
    input[type="number"]::-webkit-outer-spin-button {
        height: auto;
    }
    
    input[type="search"] {
        -webkit-appearance: textfield;
        -moz-box-sizing: content-box;
        -webkit-box-sizing: content-box;
        box-sizing: content-box;
    }
    
    input[type="search"]::-webkit-search-cancel-button,
    input[type="search"]::-webkit-search-decoration {
        -webkit-appearance: none;
    }
    
    input[type="color"],
    input[type="date"],
    input[type="datetime"],
    input[type="datetime-local"],
    input[type="number"],
    input[type="range"],
    input[type="tel"],
    input[type="week"] {
        font-feature-settings: kern 0, liga 1, calt 1, pnum 1, tnum 0, onum 0, lnum 1, zero 0;
    }
    
    fieldset {
        border: 1px solid silver;
        margin: 0 2px;
        padding: 0.35em 0.625em 0.75em;
    }
    
    legend {
        border: 0;
    }
    
    textarea {
    	resize: vertical;
        overflow: auto;
    }
    
    optgroup {
        font-weight: 700;
    }
    
    table {
        border-collapse: collapse;
        border-spacing: 0;
    }
    
    tbody,
    caption {
        font-feature-settings: kern 1, liga 1, calt 1, pnum 0, tnum 1, onum 0, lnum 1, zero 1;
    }

    Ответ написан
    Комментировать
  • Как поступить с css в многостраничном сайте?

    BormotunJedy
    @BormotunJedy
    Верстальщик
    На больших проектах логично создавать отдельные файлы стилей. В scss или sass или less, которые потом собираются в один css. Насчет комментариев внутри кода - утяжеляют. Иногда это бывает критично.
    Стили уникальных страниц прописываю с одинаковым началом - например, about__ или shop__.
    Тогда при сборке уникальные стили страницы идут один за другим и не перекликаются с другими страницами. И править при необходимости такой файл легче.
    Alex правильно говорит, по уму все стили еще на стадии подготовки к верстке должны быть разделены на группы.
    Ответ написан
    Комментировать
  • Как поступить с css в многостраничном сайте?

    @sewaca
    Если планируется натяжка на какой-то движок, то одним файлом будет удобнее, просто добавляй комментарии в код по типу /* About */ и т.д.
    Если натяжка не планируется, то лучше делать отдельными файлами. Так и по оптимизации (pagespeed) будет лучше, и верстать удобнее
    Ответ написан
    Комментировать
  • Как поступить с css в многостраничном сайте?

    Kozack
    @Kozack Куратор тега CSS
    Thinking about a11y
    В идеальном мире все стили у вас разбиты по группам:
    Общие стили -- которые применяются на всех или на связанных страницах сайта. (Макет, какая-то шапка, подвал)
    Специфичные -- которые применяются на одной или нескольких конкретных страницах. (Таблица цен на одной странице, или другой макет для админки)

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

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

    Критичные стили. Это всё что касается первоначальной отрисовки. Эти стили загружаются как можно раньше. Они имеют высокий приоритет и блокируют рендеринг страницы. Чем такие файлы меньше тем лучше! Всё что можно загрузить потом -- нужно загружать потом.
    Не критичные стили -- это всё остальное.

    На пример: Форма. Общие стили формы -- критичный CSS. А стили для отображения условного попапа с подтверждением отправки -- не критичный. В результате, браузер скачивает критичный CSS, отображает страницу, пользователь уже может с ней работать и заполнять форму, а браузер в фоне дозагружает остальной CSS для попапа.

    Но, это картина идеального мира и всё нужно изучать для конкретного случая. Например, если у вас практически весь CSS критичный, и только несколько десятков правил можно вынести в "не критичный" то вы много в производительности не выиграете, а скорее проиграете из-за накладных сетевых расходов.

    Или другой пример. Предположим, что на вашем сайте все страницы достаточно уникальны. В таком случае, разделять "общие" и "специфичные" стили может быть лишним или слишком затратным для поддержки.
    Ответ написан
    5 комментариев
  • Как в html таблицах переносить элемент на следующую строку (в письмах для Outlook)?

    sergski
    @sergski
    web-developer
    оставьте в строке 1 столбец, а в нём ваши блоки, но каждый в таблице с align="left"
    пример
    Ответ написан
    2 комментария
  • Почему задают такие свойства для елемента с position absolute?

    BormotunJedy
    @BormotunJedy
    Верстальщик
    Чтобы не сидеть часами у монитора и не писать бесконечные медиа-запросы. Таким незамысловатым образом верстальщики сокращают количество кода, делают его удобочитаемым, а поведение элементов на странице - предсказуемым. И это желательно делать не некоторым верстальщикам, а всем поголовно.
    Ответ написан
    2 комментария
  • Что из себя представляет вёрстка?

    BormotunJedy
    @BormotunJedy
    Верстальщик
    Верстка во фрилансе - это вид сложной работы по добыче денег посредством владения навыком выполнять работу веб-верстальщика по заказу найденного и убежденного вами в том, что вы справитесь с этой работой, заказчика.
    Отличается от работы в офисе тем, что фрилансер сам ищет заказы, заказчика и ведет с ними все переговоры - от получения заказа в работу до получения от заказчика денег.
    Правда, для того. чтобы устроиться в офис работать верстальщиком, у вас должен быть приличный багаж умений, навыков и знаний, подтвержденный дипломами/сертификатами и толстым портфолио.
    А у фрилансера есть шанс найти заказчика, который портфолио не спросит. Но и платить такой заказчик много не намерен.
    Про практические аспекты верстки мои коллеги подробно ответили.
    Удачи!
    Ответ написан
    Комментировать