Задать вопрос
  • Есть ли возможность во Vue.js конвертировать изображения в webp сохраняя исходную картинку для кроссбраузерности?

    @alex_p95
    Учусь
    Либо перекинуть на сборщик, либо на какой-нить image cdn если нужно трансформить в рантайме
    Ответ написан
    Комментировать
  • Можно ли конвертировать картинку в формат webp при сохранении её через админку, чтобы она сохранялась в ту же папку, что и оригинальная?

    no_one_safe
    @no_one_safe
    use Bitrix\Main\EventManager;
    EventManager::getInstance()->addEventHandler("main", "OnAfterFileSave", array('MyClass', 'execute'));
    EventManager::getInstance()->addEventHandler("main", "OnPhysicalFileDelete", array('MyClass', 'executeDelete'));
    EventManager::getInstance()->addEventHandler("main", "OnAfterResizeImage", array('MyClass', 'executeResize'));
    
    class MyClass
    {
    
        function execute($arFields)
        {
            if (intval($arFields['HEIGHT']) > 0 && intval($arFields['WIDTH']) > 0) {
                if (strpos($arFields['CONTENT_TYPE'], "image/") !== false && strpos($arFields['CONTENT_TYPE'], "svg") === false) 
               {
                   $strPath = \Cfile::GetFileSRC($arFields);
                    //Make Webp
                }
            }
        }
    
        function executeDelete($arFields)
        {
           $strPath = \Cfile::GetFileSRC($arFields);
           //Delete webp
        }
        
        function executeResize($strPath)
        {
            $obFile = new \Bitrix\Main\IO\File(\Bitrix\Main\Application::getDocumentRoot() . $strPath);
            if (strpos($obFile->getContentType(), "image/") !== false && strpos($obFile->getContentType(), "svg") === false) {
               //Make Webp
            }
        }
    }
    Ответ написан
    Комментировать
  • Есть ли возможность конвертировать изображения в webp на стороне Nginx "на лету"?

    smilingcheater
    @smilingcheater
    Посмотрите в сторону https://www.modpagespeed.com/ - модуль для nginx, который умеет выполнять кучу оптимизаций с отдаваемым контентом, в том числе конвертировать изображения в webp если браузер его поддерживает. Установка, правда, не совсем тривиальная - требуется для nginx собирать из исходников. https://www.modpagespeed.com/doc/build_ngx_pagespe...
    Ответ написан
    Комментировать
  • Должны ли разработчики понимать абсолютно весь проект?

    @d-stream
    Готовые решения - не подаю, но...
    Рабочим лошадкам это может оказаться вредным - будут отвлекаться на рацухи)))))
    Собственно все современные подходы промышленного программирования позволяют сделать из отдельного программиста мелкий винтик, крутящийся в очень узком участке.
    А широкий обзор (абстрагируясь от частностей) - это уже удел "верхних"
    Ответ написан
    Комментировать
  • Должны ли разработчики понимать абсолютно весь проект?

    saboteur_kiev
    @saboteur_kiev Куратор тега Программирование
    software engineer
    ООП был придумано именно для этого, чтобы ты примерно знал проект, а хорошо ковырял те задачи, которые висят на тебе.
    Ответ написан
    Комментировать
  • Должны ли разработчики понимать абсолютно весь проект?

    @mkone112
    Начинающий питонист.
    В идеале да. И к этому идеалу нужно стремиться. Чем лучше знаешь проект - тем лучше выполняешь задачи, тем больше денег получаешь(если не идиот конечно).
    Ответ написан
    1 комментарий
  • Должны ли разработчики понимать абсолютно весь проект?

    Griboks
    @Griboks
    В теории да. На практике есть менеджер, который распределяет задачи так, что можно вообще ничего не знать.
    Ответ написан
    Комментировать
  • Должны ли разработчики понимать абсолютно весь проект?

    wataru
    @wataru
    Разработчик на С++, экс-олимпиадник.
    В достаточно большом проекте - это просто невозможно. Ни один человек в мире не может понимать целиком, например, хром.

    Если проект нормально структурирован, то все разработчики должны понимать примерно чем занимается каждая часть и общую архитектуру.

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

    hottabxp
    @hottabxp
    Сначала мы жили бедно, а потом нас обокрали..
    Если код написан правильно, разделен на логические части, и т.д. - не должен. Да и может целой жизни не хватить, чтобы разобраться.

    Давно читал книгу по разработке ядра Linux(еще времен Linux 2.6). Так в ней написано, что людей, которые полностью разбираются как работает ядро, можно пересчитать на пальцах одной руки. Но тем не менее, это не мешает ему активно развиваться и по сей день.
    Ответ написан
    1 комментарий
  • Зачем использовать файл class.php в компоненте в 1С-Битрикс?

    udjin123
    @udjin123
    PHP, Golang, React
    Смысла много, хоть какое то разделение и оформление кода, из практического тот же новый ajax в компонентах только через class. И вообще использование сomponent.php устарело, используйте class.php
    Ответ написан
    1 комментарий
  • Как автоматически продлять время жизни сессии?

    Immortal_pony
    @Immortal_pony Куратор тега PHP
    Не используйте сессии PHP - храните сессию в файле или в БД. Идентификатор сессии на клиентской стороне храните в "вечной" (на 100 лет, например) cookie.

    Ну и дальше спокойно реализуйте алгоритм:
    1. Пользователь заходит на сайт
    2. Вытаскиваем из cookie id сессии
    3. Находим сессию.
    4. Убеждаемся, что сессия не протухла
    5. Продлеваем жизнь сессии
    6. в __desctruct() сохраняем сессию в файл или в БД
    Ответ написан
    Комментировать
  • Хорошей ли аналогией для ООП является таксономия живого мира?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    наследование это вообще лишь маленький кусочек ООП.
    Ответ написан
    Комментировать
  • Зачем нужны байты?

    samodum
    @samodum
    Какой вопрос - такой и ответ
    В байте не всегда 8 бит.
    К тому же, в компьютере данные передаются по шинам данных сразу байтами, двойными словами и т.д., но не битами по отдельности. Т.е., битами параллельно по одной шине данных. Раньше это были 8-битные ШД (ZX Spectrum), потом 16-битные (Sega Mega Drive 2 вспоминаем сразу же), потом 32 и 64-разрядные. Очень удобно.
    Ответ написан
    3 комментария
  • Зачем нужны байты?

    wisgest
    @wisgest
    Не ИТ-специалист
    Строго говоря 8 бит — это не байт, а октет, а байт — это наименьшая адресуемая единица памяти (у отдельных битов собственного адреса нет). Просто обычно эти понятия совпадают.
    Ответ написан
    Комментировать
  • Зачем нужны байты?

    fzfx
    @fzfx
    18,5 дм
    байты нужны примерно затем же, зачем и килограммы. не всегда нужна точность до грамма, не всегда нужна точность до бита.
    если документ занимает 414 байт, я не вижу какого-то смысла париться и оперировать вместо этого значением в 3312 бит.
    Ответ написан
    Комментировать
  • Как лучше провести валидацию силы пароля?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Это спорный вопрос. Имеет смысл проверять по таблице самых популярных паролей (серверная валидация) и отказывать, если пароль оттуда.
    Ни в коем случае не проверяйте сложность пароля фактом наличия в нём символов из определённых групп. Нужно просто считать энтропию пароля в битах и задать пороговую допустимую энтропию.
    К примеру, если у пользоватля длинный пароль из 30 символов, ему совершенно необязательно добавлять символы разного регистра, цифры и всякие запятые, они практически не повлияют на сложность, зато могут повлиять на способность пользователя как следует запомнить свой пароль (где там какая цифра, куда дефис и где именно скобки...)

    Итак,
    1. накладывать оганичения нужно только на энтропию пароля, остальное пойдёт только во вред.
    2. ограничения должны нести рекомендаельный характер, имеет смысл сделать два порога энтропии. Совсем слабые пароли не допускать, средние допускать с предупреждением. Пусть пользователь осознаёт сложность пароля и сам соотносит ее с рисками злонамеренного подбора. Порог энтропии можно проверять на клиенте, базу популярных паролей придётся чекать на сервере.
    3. как следует солите пароли и не храните их в открытом ввиде. Это правило следовало бы вынести на первое место, но это не рейтинг мер, а просто важные замечания. Соль для каждого пароля можно хранить рядом с хешем пароля через разделитель, рядом же можно указать и название алгоритма хеширования.
    4. сложность пароля - не панацея. Нужно делать эффективную систему распознавания попыток подбора пароля. Если сильно ограничить скорость подбора пароля то пароль можно делать простым. Пример тому - пинкоды на вашей банковской карте. У вас всего три попытки неправильного ввода на сутки, ошибочные попытки на следующий день вовсе окирпичат вашу карточку. Не бывает простых решений. Нужно понимать также, что пароли могут брутфорситься не с целью подбора, а с целью блокирования входа законного владельца аккаунта.
    5. Не забывайте про двухфакторную авторизацию. Это важно.
    6. Обновляйте сессию пользователя при штатной работе в аккаунте. Не вынуждайте каждый раз вводить пароль по несольку раз на день. Этим, к примеру, постоянно грешит алиэкспресс. Но у них многое ерез задницу.
    7. Не делайте нестандартных форм авторизации, важно, чтобы ваша форма нормально работала с основными стандартными менеджерами паролей. Если пользователь пользуется менеджерами паролей, то это его осознанный выбор, он может быть вполне обоснован. Это гораздо лучше, чем пароль на стикере, прилепленый к монитору.
    8. Если делаете API, не требуйте использования в нём паролей. Сделайте нормальный менеджмент ключей, не заставляйте светить пользовательские пароли в открытом виде в скриптах и исходниках. Не все, пока еще, грамотно работают с секретами.
    Ответ написан
    1 комментарий
  • Как лучше провести валидацию силы пароля?

    @Giperoglif
    если это критично то без серверной валидации не обойтись т.е. в идеале и там и там
    Ответ написан
    Комментировать
  • Чем плохо выносить повторяющиеся элементы дизайна в отдельные файлы и подключать их потом с помощью PHP?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Тут, как обычно, не одна проблема, а три.

    Первая проблема - это, как всегда, неумение задавать вопросы.
    Вот и сейчас - вопрос "чем плохо ходить пешком?" Что можно ответить на этот вопрос?
    Но потом выясняется что вопрос на самом деле "Я живу в 20 километрах от работы. Чем плохо ходить на работу пешком?".

    То есть вопрос у нас на самом деле, "Чем плохо выносить повторяющиеся элементы HTML в отдельные файлы и подключать их потом с помощью include?". Этот вопрос уже будет более осмысленный, и на него даже можно дать ответ не выглядя при этом идиотом.

    Вторая проблема заключается в том, что подход с "хидером и футером" реально неудобен и устарел уже лет 20 как. И вместо него используются шаблонизаторы. Тупо редактировать хтмл удобнее когда он лежит в одном файле, а не в header.php. footer.php. menu.php, banners.php и еще 10 файлах.
    И это я даже не заикаюсь о случае, когда на разных страницах надо поключать разные файлы стилей и скриптов.

    И третья проблема заключается в том, что хотя в принципе и можно что-то несложное накалякать с хидером и футером, но поголовно все новички все равно клепают их неправильно - а именно вкрячивают хидер до того, как скрипт вообще начнет работу. И потом имеют все прелести невозможности вывести НТТР заголовок, поменять что-то в хидере в зависимости от выводимых данных, поменять формат вывода или аварийно завершить работу.
    Ответ написан
    Комментировать
  • Чем плохо выносить повторяющиеся элементы дизайна в отдельные файлы и подключать их потом с помощью PHP?

    delphinpro
    @delphinpro Куратор тега PHP
    frontend developer
    Тем, что в случае использования php вам совершенно ничего не мешает подрубить шаблонизатор, например twig, и делать разбивку страницы более или менее красиво.

    К примеру, задать общий лейаут, прописать в нем общие блоки, и страницы расширять от него.

    base.twig
    <html>
    <head></head>
    <body>
      <header>...</header>
      <main>{% block main %}{% endblock %}</main>
      <footer>...</footer>
    </body>
    </html>


    index.twig
    {% extend 'base.twig' %}
    {% block main %}
      Главная страница
    {% endblock %}


    about-us.twig
    {% extend 'base.twig' %}
    {% block main %}
      Интереснейший текст о компании
    {% endblock %}
    Ответ написан
    1 комментарий
  • Чем плохо выносить повторяющиеся элементы дизайна в отдельные файлы и подключать их потом с помощью PHP?

    catdesign
    @catdesign
    Веб-разработчик
    Абсолютно ничем не плохо. Все ровно наоборот.
    Нужно руководствоваться поставленной задачей. Если у вас одностраничный сайт, то выносить все отдельно нет смысла. Хотя в особо длинных лендингах это позволяет облегчить читаемость кода.

    Что касается многостраничных сайтов, то разбиение на фрагменты жизненно необходимо, потому что главное правило программиста - не дублировать код. Ленивый программист = хороший программист!
    Ответ написан
    Комментировать