Задать вопрос
  • В какой контейнер ставить сертификат Lent`Encrypt в NGINX-front или NGINX-backend?

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

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

    Серверное решение без JS более надёжно:

    Реализуем паттерн Post/Redirect/Get (PRG) плюс одноразовый уникальный токен.

    - Допустим у нас форма по адресу "/form".
    <form id="myForm" action="/save-data" method="post">
      <!-- ...поля... -->
      <button type="submit">Отправить</button>
    </form>


    - Когда сервер принимает POST запрос по адресу, по которому была отправлена форма "/save-data", он проверяет валидность данных, и ежели всё верно, то не рисует ответ с успешным успехом прямо по этому адресу, а делает серверный редирект 303 на страницу "/success". Т.е. другой адрес. Почему 303? Потому что такой редирект даёт браузеру понять, что на страницу "/save-data" нет смысла возвращаться и хранить его в истории, ведь 303 нам сказал искать контент по другому адресу.
    - Это решает проблему с клавишей "F5" (обновление страницы). К тому же в истории у нас всё нормально без никакого редиректа.
    - Однако кнопка назад может заставить браузер вернуться на страницу с заполненной формой "/form". И повторная отправка сработает.

    Для решения этой проблемы мы вводим для каждого отображения формы специальный уникальный токен.

    - При загрузке страницы с формой генерируем этот токен на сервере.
    - Сохраняем токен в сессию
    - Рисуем в HTML формы дополнительное невидимое поле, содержащее этот же токен.

    <form id="myForm" action="/save-data" method="post">
      
      <input type="hidden" name="form_token" value="уникальное_значение_12345">
      
      <!-- ...другие поля... -->
      <button type="submit">Отправить</button>
    </form>


    Когда пользователь нажимает кнопку Отправить правильно, без возвратов назад, происходит следующее:

    1. Сервер получает POST запрос с данными формы на "/save-data"
    2. Забираем значение form_token и сравниваем его с сохранённым ранее токеном из сессии.
    3. Если токены совпадают, то немедленно удаляем его из сессии. Это и есть решение.
    4. Делаем редирект на страницу "/success"
    5. Пользователь видит красивую зелёную галочку и сообщение об успешном успехе. Он доволен.

    Если же он вернётся-таки на страницу формы через кнопку Назад, увидит там всё ту же заполненную форму с данными, и подумает, что он не отправил данные, и попробует снова отправить форму, то произойдёт следующее:

    1. Сервер получает POST запрос с данными формы на "/save-data"
    2. Забираем значение form_token и сравниваем его с сохранённым ранее токеном из сессии.
    3. Т.к. токены не совпадают (в сессии токена нет, мы его удалили ранее), то делаем редирект на страницу "/error", где сообщаем пользователю, что он уже отправлял эту форму раньше, и всё в порядке, пусть не переживает.
    4. Пользователь видит сообщение и утирает пот со лба. Он доволен.

    Решение только выглядит сложным. На самом деле оно простейшее.

    Очистку данных формы конечно можно делать, очищая поля формы с помощью Javascript. Но... Зачем?
    Но если надо, то обрабатывайте событие 'pageshow'. Проверяйте, ежели браузер действительно загрузил страницу из bfcache, и очищаете форму. Можно еще и кнопку снова активировать, если задизаблили её раньше.

    window.addEventListener('pageshow', function(event) {
      // event.persisted бывает true, когда страница загружается из bfcache
      if (event.persisted) {
        const form = document.getElementById('myForm');
        if (form) {
          form.reset(); // Сбрасываем все поля формы
          const button = form.querySelector('button[type="submit"]');
          button.disabled = false; // Убедимся, что кнопка снова активна
          console.log('Страница восстановлена из кэша. Форма сброшена.');
        }
      }
    });
    Ответ написан
    1 комментарий
  • Обьясните в чём суть инкапсуляции?

    TrueBers
    @TrueBers
    Гуглю за еду
    Оу, май, 4 человека ответили, и ни один не понимает, что такое инкапсуляция... деградация какая-то, алё!

    Причём тут защита данных? Причём тут контроль доступа? Сокрытие данных? Геттеры, сеттеры? private, public?
    Это всё не имеет никакого отношения к инкапсуляции, это всё побочные эффекты, либо способы реализации в конкретном языке.

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

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

    На этом всё, это и есть инкапсуляция.
    Ответ написан
    Комментировать
  • Как написать бота отслеживающего скидки на маркетплейсах?

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

    sergiks
    @sergiks Куратор тега Веб-разработка
    ♬♬
    github pages

    1. создать репо с названием username.github.io, где username – точное имя вашего аккаунта или организации, в которой это репо
    2. в нём создать index.html
    3. запушить в основную ветку main
    4. открыть https://username.github.io


    Потом можно настроить и свой домен на этот сайт.

    Единственная неприятность, если сайт требует билда скриптов и прочего, в итоге придётся коммитить и скомпилированные файлы.
    Ответ написан
    Комментировать
  • Что нужно знать про ООП?

    @Evident
    От ООП в php одно название, потому что даже перегрузки методов нет.
    Чтобы проще постичь ООП, переходите на Java или C#.
    Ответ написан
    8 комментариев
  • Правда ли что рынок веб разработки "перегрет"?

    OTCloud
    @OTCloud
    Программирование и Архитектура ПО
    100% перегрет, но не программистами или веб-мастерами, а индивидами, которые решили что веб это просто и легко и не стоит сильно париться над своими скиллами и знаниями.
    Ответ написан
    8 комментариев
  • Может ли быть API не как API?

    @karminski
    Senior React.JS Developer
    Так вот, для меня, - все AJAX запросы это API

    В этом ваша ошибка. Аякс это далеко не апи! Аякс это всего лишь асинхронный запрос к серверу. А что там на сервере - это другое дело.

    Апи можно дергать как Аяксом, так и curl и другими методами.
    Ответ написан
    Комментировать
  • Есть ли сайт, где собраны общепринятые практики программирования?

    Moskus
    @Moskus
    Естественно, нет, потому что всё, что вы описали - это не какое-то тайное знание, которое можно только запомнить, а логичные приёмы, которые следуют из знания фундаментальных принципов и анализа требований к продукту. Если попытаться заменить фундаментальные знания таким сборником прецедентов, он получится гигантским и совершенно непригодным для освоения - столько всего просто нельзя запомнить. Объем фундаментальных знаний - на порядки меньше объёма частностей, которые из них выводятся, но сложность этих знаний, при этом, выше. Кто фундаментальные знания не осилил, остаётся говнокодером, пока не осилит.
    Ответ написан
    Комментировать
  • Чем опытнее разработчик, тем меньше соблюдается принцип KISS?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Принцип KISS не означает что надо использовать самые примитивные инструменты.
    Он означает, что не надо переусложнять систему без нужды.
    Если так рассуждать, так и высшее образование не нужно: "Дед отличные бани строил, хотя вовсе был неграмотный. Я и без сопромата небоскреб построю!"
    Если вы пока ещё не понимаете назначение всех этих "лееров, провайдеров и репозиториев", это не значит, что они вообще никому не нужны.

    Для того, чтобы упростить управление системой, её надо усложнить.
    Этот принцип относится к любой области человеческой деятельности, от постройки ракет до управления государствами.
    Чем сложнее система, тем больше накладные расходы на ее управление. Хоумпейдж с котиками можно и нужно делать примитивными средствами. В большом проекте надо сразу закладываться на будущую расширяемость. То есть, заранее делить ответственность между "леерами".

    И кстати. Код, в котором "всё друг на друге завязано" - это очень плохой код. Собственно, предназначение всех этих "лееров, провайдеров и репозиториев" как раз в том, чтобы компоненты были как можно более независимы друг от друга.
    Ответ написан
    1 комментарий
  • Кто знает простые альтернативы JQuery?

    VanillaJS, очень хороший фреймворк. Перешел на него с jQuery и всем советую.
    Ответ написан
    3 комментария
  • Какой язык/фреймворк выбрать?

    neatsoft
    @neatsoft
    Life is too short for bad software
    Фреймворки нужны для упрощения и ускорения разработки - избавления от бойлерплейта и защиты от типичных ошибок. Можно ли всё тоже самое сделать вручную? Можно, но не нужно - большая часть времени уйдет на изобретение велосипедов, некоторые из которых будут медленными или небезопасными.

    По моему опыту, Django позволяет реализовывать типичные задачи вдвое быстрее, чем Laravel (использовал оба). Во многом это заслуга Python и сложившейся вокруг него экосистемы. Здесь выбор очевиден.

    VueJS скорее с ReactJS нужно сравнивать, а не с Angular, т.к. Angular это фреймворк, а VueJS и ReactJS - библиотеки. Все три помогают быстро и эффективно создавать фронтенд современных веб приложений, но делают это по разному. В качестве первого мягко (ненастойчиво) рекомендую изучить VueJS.

    p.s. Вне зависимости от выбора, не стоит заниматься веб-разработкой под windows. Стандартные среды - Ubuntu 18.04 (либо любой другой, но не слишком маргинальный дистрибутив) и MacOS.
    Ответ написан
    5 комментариев
  • Актуально ли изучать nodejs для бекенда или лучше оставаться на php?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Изучать надо программирование.
    Все эти вопросы, "Какую машину лучше учиться водить - Рено или Фольксваген?" - это детский сад, честное слово.
    Если для вас потолок - это несколько десятков встроенных функций одного языка, то всё равно что учить - ковыряться помаленьку можно на любом.
    Программист же мыслит не инструкциями, а алгоритмами, паттернами, потоками данных, структурами объектов, шинами сообщений. На каком языке это все реализуется - не принципиально.
    Ответ написан
    2 комментария
  • Как правильно писать на ООП?

    Xuxicheta
    @Xuxicheta
    инженер
    У вас линейная обработка данных, это одна процедура, а вы сделали класс ради класса.

    Вообще в js я начал стараться предпочитать функциональный стиль там, где это возможно.
    Даже методы пишу максимально похожими на чистые функции. Так проще переиспользовать их в других местах и, вообще, понятнее что происходит.
    А то уже замучался разбираться с этим хардкорным ООП, которое встречается сплошь и рядом.

    Качественный класс написать сложно, плюс наследование в js не особо рекомендуется. А для композиции лучше подходят простые функции.
    Ответ написан
  • Подготовка к собеседованию Junior Ruby on Rails?

    c3gdlk
    @c3gdlk
    Ментор в http://rubyboost.ru/
    Я уже выучил Ruby, RoR


    до сих пор не могу сказать, что выучил рельсы и руби =)

    По сабжу

    REST, MVC, структура проекта, в каких папках что лежит, включая папку config.
    что такое представление, паршиалы, по моделям полностью - скоупы, ассоциасии. валидации, коллбеки
    контроллеры - before_action, что уже лежит в ApplicationController
    Unix - что такое приложение, процесс и порт. Что делать если при старте сервера пишет, что порт 3000 уже используется.
    По руби - идиома @a ||= b, блоки, циклы, что делаeт attr_accessor, что такое символ, константы в руби.
    По базам - прошу привести примеры какие запросы генерирует та или иная цепочка DSL ActiveRecord, например
    User.where(id: 1), User.where(id: [1]), User.where(id: []) И таких вариантов куча, нет смысла пытаться заучить, нужно разбираться.

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

    Кроме того, предлагаю банальщину - пройтись по основам railsguides и убедиться, что верно понимаете соглашения фреймворка. Rails построен на соглашениях и тот кто в них хорошо разобрался имеет высокий шанс получить работу.

    Например, большинство кандидатов на вопрос, что в имени представления index.html.erb означает html отвечают, что это язык разметки в котором вернется ответ. Т.е. они просто строят логичное предположение и не пытаются его проверить. И таких, казалось бы простых вопросов, у меня целая пачка. В большинстве случаев кандидат уходит с пониманием, что ничего на самом деле и не знает.

    P.S. лучше знать что-то одно хорошо, чем много всего по немногу.

    Но, в каждой компании по разному.
    Ответ написан
    Комментировать
  • Как организовать структуру для spa приложения (backend, frontend)?

    dmitriylanets
    @dmitriylanets
    веб-разработчик
    на самом деле вы должны проектировать ваш rest отталкиваясь от предметной области, от сущностей, а там нет разделения публичка, админка
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    Заказчик хочет чтобы разработчик сделал сложное приложение.

    Причина 1: обычно заказчик хочет, но не знает чего конкретно. Фишка в том, что разработка приложения, у которого ещё нет аналога - это... не только разработка приложения. Это ещё и выяснение того, что действительно нужно, начиная с пожеланий по UX, и заканчивая оптимизацией бизнес-процессов во всей компании (это когда заказчик внезапно говорит "слушайте, и правда, на кой чёрт мы печатаем эту накладную каждый раз").

    КПД получается крайне низок.

    Причина 2: вы не учитываете причину 1 при расчёте КПД и думаете, что проделали мало работы. Да, приложение ещё не готово или делается очень долго, но это не потому что вы мало работаете, а потому что работы намного больше, чем казалось.

    но идёт на удаление или переделку из-за того, что что-то не так.

    Причина/особенность 3: иногда это неизбежно: бизнес меняется, потребности - тоже.
    Иногда этого можно избежать, не заводя требования слишком "далеко" - очевидно, нет смысла реализовывать то, что УЖЕ СЕЙЧАС кажется неподходящим под требования, НО это далеко не всегда вовремя замечают. Над проектом работает много людей, у всех немного разные представления о задаче, или ещё хуже: не все и далеко не всегда говорят о проблемах с системой, которые уже виднеются "на горизонте", говоря что "в ТЗ всё написано, а мы делаем по ТЗ". Можете погуглить статьи о стоимости ошибок на разных этапах разработки.

    Причина 4: заказчик, разработчики или и те и другие не умеют останавливаться и выбирать необходимый и достаточный функционал для первого или очередного релиза. Я в последнее время убеждаюсь, что это целая наука - вовремя остановиться и не расширять список "супернужных" фич, из которых треть окажется почти невостребованными. Особенно часто это бывает, когда бизнес уже работает как-нибудь (например, на экселевских табличках или Access-овских базах), а теперь пришла пора автоматизации, но релиз постоянно откладывается, потому что "и это хочется, и то бы сразу сделать". Иными словами, иногда нужно решиться на гарантированные переделки в будущем ради релиза сейчас. Оценка возможности и стоимости таких "переделок" - т.е. подождать и переделать сейчас или зарелизиться и переделать потом (соответственно, с удорожанием "переделок") - и есть та самая наука. Разработчик обычно видит только архитектуру, и раньше понимает её недостатки/ограничения, ему сложно решиться на релиз того, что не будет идеально решать поставленную задачу.
    Ответ написан
    Комментировать
  • В чём причина постоянного переделывания кода?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    В неумении разработчика проектировать гибкую архитектуру приложения и писать расширяемый код.
    Ответ написан
    2 комментария
  • В чём причина постоянного переделывания кода?

    titov_andrei
    @titov_andrei
    All my life I learn - and die a fool!
    Ремонт ЗАКОНЧИТЬ нельзя — его можно только ПРЕКРАТИТЬ.
    https://www.inpearls.ru/
    - © Михаил Жванецкий
    Ответ написан
    Комментировать