Задать вопрос
  • Какие есть годные альтернативы OpenServer?

    motokraft
    @motokraft
    Кратко о себе
    Docker - он конечно будет сложнее чем OpenServer, но если научиться то думаю оно того стоит
    Ответ написан
    4 комментария
  • Как в параметре маршрута использовать значение с точкой?

    yarkov
    @yarkov Куратор тега Vue.js
    Помог ответ? Отметь решением.
    Интересная ситуация. Очевидно что путь с точкой обрабатывается как "имяфайла.расширение". Вот на стэковерфлоу кажется ваша проблема описана
    https://stackoverflow.com/questions/71029445/handl...
    Ответ написан
    Комментировать
  • Как правильно мержить в main из dev, если там есть незаконченные фичи?

    bingo347
    @bingo347
    Crazy on performance...
    Фича ветки делаем только от актуального main.
    Для проверки мержим фича-ветку в dev, но не удаляем.
    Когда одна или несколько фичей проверены и готовы, то делаем от main релизную ветку и мержим туда все готовые фичи, прогоняем тесты и если всё ок, то мержим релизную вету в main.
    Ну и полезно мержить main в фича ветки, когда main обновился.
    Ответ написан
    Комментировать
  • Подключение boostrap vue?

    i229194964
    @i229194964
    Веб разработчик
    Разделите стили для каждого вашего компонента.
    Импортируйте стили компоненты в соответствующий файл стилей.
    <style scoped>
    @import './MyComponent.css';
    </style>
    Ответ написан
    Комментировать
  • Какие есть самые распространённые причины появления багов?

    "самой распространённой причины" не существует. Она будет сильно зависеть от конкретного продукта и процессов разработки.

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

    2. Не полная спецификация. Например в спецификации не было описано, как система будет себя вести при ошибках - разработчик при реализации решил додумать сам.
    Либо ещё может произойти из-за того что спецификация сама себе противоречит или её нельзя реализовать в полной мере за адекватное время.

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

    4. Регресс. Разработчик нормально реализовал спецификацию, но тестировщик проверил только новую фичу и не стал проверять регресс - в итоге новая фича работает, а какая-то старая - сломалась, из-за того что её задели при разработке.

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

    6. Во время разработки у заказчика поменялись планы. Старая спецификация больше не отвечает новым требованиям. Нужны доработки.

    Чтобы минимизировать вышеперечисленное, нужно:
    1. Плотное общение между разработчиком, аналитиком, и QA.
    2. QA должен начинать тестирование ещё на этапе спецификации
    3. Разработчик должен сообщать аналитику о всех случаях, когда он не может что-то реализовать или о каких-то пробелах.
    4. Разработчик должен сообщать QA о возможном регрессе в других фичах.
    5. Должны быть автотесты, чтобы уменьшить нагрузку на QA и чтобы минимизировать шанс на регресс
    6. Тестирование должно обязательно производиться на том оборудовании и в том окружении, на котором система будет потом работать.
    7. Чем чаще релизы - тем лучше.
    Ответ написан
    1 комментарий
  • Какой VPN выбрать?

    @KingAnton
    Например amnezia, заодно сможете протестить разные протоколы
    Ответ написан
    1 комментарий
  • Как запретить инвертирование цвета при темной теме браузера?

    @ymfront Автор вопроса
    Нашел следующее решение для запрета темной темы:

    HTML:

    <meta name="color-scheme" content="only light">

    CSS:

    :root {
         color-scheme: only light;
    }
    Ответ написан
    Комментировать
  • Какие отличия в верстке под ios и android?

    @strelok011
    Надо бы насобирать еще материал, но
    1. по поводу лагов - чем меньше фильтров, теней, прозрачностей - тем айфону легче. Не умеет в ускорение.
    2. скролл - это отдельная БОЛЬНАЯ тема у айфонов. Причем у разных версий IOS они разные. Проблема в том, что реализация демонстрации куска верстки длинной страницы в окне браузера просто уродская. На старых айфонах, к примеру, не работал position fixed.
    3. Никогда, просто НИКОГДА не пытайся прибить скользящее меню к низу страницы. Это и на андроиде выйдет дичайшим геммороем из-за автовсплывающих или автоскрывающихся панелей инструментов. Это ад и боль
    4. В качестве задачи со звездочкой - попробуй реализовать модалку поверх контента, в которой свой скролл, и попробуй заблочить скролл контента в фоне. Айфон тебя порадует своими чудесами.
    5. Думаю, будет весело перебирать высоту вьюпорта и подбирать позиционирование, переключаясь то на px то на wh.
    6. Имей в виду - как бы не назывался браузер на айфоне - он использует одно и то же ядро сафари, специфичное для версии ios, так что глюки переносятся.
    7. Ловил проблемы (тут уже не в платформе а в реализации сафари) именно в сафари если делаем display: flex, flex-direction: reverse, отваливается gap. Без реверса - всё гуд. На других реализациях таких проблем не встречал.
    8. Если ты попробуешь поиграть с параллаксом самописанным - получишь ачивку "слабоумие и отвага"
    Ответ написан
    3 комментария
  • Какой WYSIWYG редактор лучше подойдет на React?

    Azurre
    @Azurre
    Web Developer
    Ответ написан
    Комментировать
  • Какой ноутбук выбрать?

    memxr1es
    @memxr1es
    Чел
    Советую Honor MagicBook 15 (либо 16)

    Лично пользуюсь уже год, жалоб нет, да и комплектация приятная (у меня 16 gb оперативы, Ryzen 4600H)
    Компактный, легкий, стильный.

    По цене выйдет от 75к до 90к (в зависимости от начинки).

    Либо можешь взять Apple MacBook на чипе M1
    Ответ написан
    3 комментария
  • С чего начать изучение автоматизации тестирования?

    @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/ используя вот это.
    Ответ написан
    Комментировать
  • Зачем нужно усложнять код?

    Aetae
    @Aetae Куратор тега JavaScript
    Тлен
    В твоём примере последняя итерация лишняя - i выходит за пределы массива, тебе надо было написать либо так:
    function funk (arr) {
      for(let i = 0, length = arr.length - 1; i < length; i++) {
        if(arr[i] === arr[i+1]) {
          return true;
        }
      }
      return false;
    }

    либо, лучше, так:
    function funk (arr) {
      for(let i = 1; i < arr.length; i++) {
        if(arr[i - 1] === arr[i]) {
          return true;
        }
      }
      return false;
    }

    Также заметь, что в современном JS никто не использует сравнение с приведением типов(==) из-за его ненадёжности, только полноценное сравнение - ===.

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

    Aetae
    @Aetae
    Тлен
    Если ты шаришь в теме - посмотри последние коммиты и всё ясно станет.
    Если ты эффективный менеджер - иди нафиг.
    Ответ написан
    Комментировать
  • Микросервисная архитектура: насколько микро? и почему не возникает проблем с долгим ожиданием?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Вы задаётесь очень сложными вопросами, развёрнутый ответ на каждый из которых вряд ли влезет в лимит символов ресурса. Чтобы разобраться с первой проблемой, стоит прочитать "Предметно-ориентированное проектирование" Эванса. Грубо говоря, микросервис должен оперировать небольшим самостоятельным подмножеством данных. Для поиска ответов на вторую и третью проблему хорошим стартом может быть "Высоконагруженные приложения" Клепмана. Да, взаимодействие внутри микросервисной системы очевидно медленнее, чем вызовы внутри монолита, у всего есть цена. Но при правильно написанном коде, правильно выбранной архитектуре и правильно построенной инфраструктуре скорость всё ещё достаточно, чтобы отвечать на запросы за доли секунды. А для согласованности приходится применять подходы вроде паттерна "сага".
    Ответ написан
    Комментировать
  • Достаточно ли знаний МатАна и линейной алгебры для карьеры в области машинного обучения?

    @ehevnlem
    Программирую с 1975, в интернете с 1993.
    никакой особой математики не надо. нейронная сеть это система достаточно простых нелинейных уравнений с очень большим количеством параметров (уже миллиарды!). Эту систему можно решить только численно, подбирая параметры с помощью многомерной оптимизации, этот процесс называется обучением. Для ускорения используют метод жадного обучения. В остальном это исскуство и мистика
    Ответ написан
  • Видеопамять. Он прав?

    KoyaKoya
    @KoyaKoya
    IT Lover
    Igor Korobeinikov, он прав, только немного перепутал терминологию.
    "Выделенная память ГП" - та память, которая находится непосредственно на самой плате видеокарты.
    "Общая память ГП" - часть памяти ОЗУ твоего ПК, которую ГП может тоже использовать.
    "Оперативная память ГП" - это сумма выделенной и общей памяти, т.е. весь суммарный объем памяти, который доступен для ГП.
    Ответ написан
    Комментировать
  • ООП в JS отличается сильно от ООП компилируемых языков?

    bingo347
    @bingo347 Куратор тега JavaScript
    Crazy on performance...
    3 принципа ООП - это миф, притом очень вредный.
    Инкапсуляция, наследование и полиморфизм относятся к ООП примерно как кухонный комбайн к варке блюд, их конечно можно использовать вместе, но и друг без друга они живут прекрасно.

    ООП - это про высокоуровневые абстракции представленные в виде объектов, а так же про взаимодействие этих объектов, путем вызова методов. Все. Никаких 3 принципов тут нет. И это примерно одинаково, что в JS, что в C#, что в Java, что в C++, а разница в реализации тут не существенна, Вы о ней знаете, только потому что абстракции текут.

    Инкапсуляция - это сокрытие сложности. Опять же все. Забудьте весь бред про приватные поля и тому подобное. Это не более чем частный случай. И замыкания - это тоже частный случай инкапсуляции. А еще, когда из модуля Вы экспортируете не все подряд (привет ReasonML), а только высокоуровневые штуки, оставляя все остальное недоступным извне. А еще когда некоторое API (REST/GraphQL/RPC/etc.) отгораживает Вас от прямого общения с базой данных - это тоже инкапсуляция.

    Полиморфизм - это возможность некоторой сущности работать с разными типами данных и возможно адаптироваться под них. А еще полиморфизм разный бывает. Помимо полиморфизма подтипов, который чаще всего и приписывают к ООП, бывают и другие. Например очень распространен параметрический полиморфизм, в большинстве языков представленный дженериками. А еще бывает ad-hoc полиморфизм (перегрузки).
    Но даже если рассматривать только полиморфизм подтипов (это когда между типами есть иерархия, то есть отношения подтип-надтип, и мы в переменную/аргумент/поле надтипа можем присвоить значение подтипа), то и тут нет не слова про ООП. Яркий пример - TypeScript, где есть тип unknown, являющийся надтипом любого другого типа и в который можно присвоить значение любого типа, а так же есть тип never, являющийся подтипом любого другого типа и который можно присвоить в любой другой тип.
    Ну и касательно JS, в нем вообще все полиморфно, ибо динамическая типизация.

    Наследование - это вообще частный случай полиморфизма подтипов, отдельно выделяют пожалуй лишь потому, что он не только про типы (как полиморфизм), а еще и про реализации, которые наследуются. И опять же, ничего тут про ООП нет. Наследование вполне может жить и без ООП,
    например во вполне себе структурно-процедурном Си
    #include <stdio.h>
    
    struct Parent
    {
        int a;
        int b;
    };
    
    struct Child
    {
        struct Parent __super;
        int c;
    };
    
    void f(struct Parent* v)
    {
        printf("a: %d\nb: %d\n", v->a, v->b);
    }
    
    int main()
    {
        struct Child v = {{10, 20}, 30};
        f((struct Parent*)&v);
        printf("c: %d\n", v.c);
        return 0;
    }


    P.S. JS вполне себе компилируемый язык, у v8 даже ассемблерный код попросить можно, который он накомпилит с Вашего JS.
    Ответ написан
    1 комментарий
  • Переработка в маленьких IT-компаниях?

    Adamos
    @Adamos
    Если вы считаете "нормальным бэкендом" узкого специалиста, который работает исключительно с сервером, а на фронте при сложении 2 и 2 получает 22 - вам нужно искать крупную компанию, где вы будете винтиком.
    Правда, искренне не понимаю, зачем. Вам страшно заниматься разнообразной работой?
    Ответ написан
    2 комментария