Задать вопрос

forestcat

Лайки

  • Правильный frontend?

    @frontendthug
    1. Первым делом разберитесь, что такое пакетный менеджер(в нашем случае npm)
    2. Попробуйте понять, как работает сборщик проекта (Gulp). Основы Gulp.
    2. Попытайтесь внедрить туда те технологии, которые Вас интересуют. ( Даже если Вы их не выучили, в инете полно гайдов по внедрениям разных технологий в Gulp .Это избавляет от использования программ типа PrePros ).
    3. Начните изучать SASS.
    4. Внедрите bootstrap-sass в свой проект.
    5. Постоянно практикуйтесь.

    Из источников, где можно всё это хорошо подучить, я могу выделить несколько:

    WebReference - много вкусностей для начинающих. Именно этот сайт помог мне в начале пути фронтендера.
    Frontender Magazine - огромное количество полезных статей.
    Zencoder - тут тоже можно много чего найти по Вашим предпочтениям.
    Прогрессор - аналогично предыдущему.

    Вам должно вполне хватить данной мной информации. Успехов!
    Ответ написан
    Комментировать
    Комментировать

  • Создание веб-страниц сайта на базе готовой БД. Как?

    @sergeystepanov1988
    Берем любой простенький фреймворк и вперед. Например Flight или Slim. Чтобы немного абстрагироваться от SQL можно прикрутить туда еще какой-нибудь ORM. Вся суть в том, что не нужно создавать 1000 страниц физически, а только один шаблон станицы, в котором в нужные места будут подставляться значения из БД.
    Ответ написан
    Комментировать
    Комментировать

  • Как сделать кнопки меню активными при нажатии?

    nepritimov_m
    @nepritimov_m
    Frontend dev.
    На стороне клиента - вешать на элемент, по которому кликнули класс (active, open - без разницы). Ну и не забыть перед этим в css-файле прописать стили для этого класса. Такой вариант прокатит при ajax-подгрузке контента.
    При стандартном варианте, как сказали выше -проверяешь соответствие url и ссылки и далее по аналогии.

    <div class="menu">
       <ul>
             <li><a class="js-menu-link active" href="index.php">Главная</a></li>
             <li><a class="js-menu-link" href="order.php">Заказ</a></li>
             <li><a  class="js-menu-link" href="payment.php">Оплата</a></li>
             <li><a  class="js-menu-link" href="conditions.php">Условия</a></li>
             <li><a  class="js-menu-link" href="contacs.php">Контакты</a></li>
       </ul>
</div>


    $('.menu').find('.js-menu-link').on('click', function () {
     if ($(this).hasClass('active')) {
         return;
     }
     $('.menu').find('.js-menu-link active').removeClass('active');
     $(this).addClass('active');
});


    Вариант на JS:
    var menuItems = document.getElementsByClassName('js-menu-link');
var onClick = function (event) {
	event.preventDefault();
  
  for (var i = 0; i < menuItems.length; i++) {
    menuItems[i].classList.remove('active');
	}
  
  event.currentTarget.classList.add('active');
};

for (var i = 0; i < menuItems.length; i++) {
    menuItems[i].addEventListener('click', onClick, false);
}
    Ответ написан
    3 комментария
    3 комментария

  • Как вы пишите веб приложения?

    @RomkaChev
    PhpStorm + Git.
    Храним код в Bitbucket.

    Основной вопрос, как я понял из обсуждения, крутится вокруг загрузки файлов на сервер.
    Используем платный сервис dploy.io.

    В репозитории следующая структура веток -
    • master - код, который находится в Production
    • development - "буфер" между master и milstone для проверки на dev-сервере
    • milestome-vX.Y.Z - Определенная стадия проекта
    • feature-N - Определенная feature


    Все изменения ведутся локально. и привязаны к одной feature-ветке. После того, как задание сделано, feature-ветка вливается в milestone-ветку (Повторяется N раз).

    Когда нужно проверить набор коммитов на dev-сервере, пушим изменения из milestone-ветки в dev-ветку и они автоматически заливаются на dev-сервер (Если нет отдельного сервера или что-то еще не позволяет развернуть тестовое окружение, то можно работать и без этого шага).

    После того, как убедились, что все нормально, вручную через web-интерфейс dploy.io заливаем master-ветку на production-сервер.
    Ответ написан
    8 комментариев
    8 комментариев

  • В каком случаи использовать --save и --save-dev в NPM?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Компиляторы-транспиляторы-трансляторы (типа Coffee, LESS, Jade), тест-раннеры, стайл-чекеры и линтеры (mocha, chai, karma, (js|es)lint, jscs), плагины для таск-раннеров (grunt-contrib-watch, gulp-jade) — все это обычно ставится как --save-dev, потому что нужно только тем, кто контрибьютит в этот проект, работает с его кодом.

    Библиотеки и фреймворки (expressjs, jquery, backbone), на основе которых работает ваш код, без которых ваш код не запустится у его потребителя — ставятся как --save.
    Ответ написан
    3 комментария
    3 комментария

  • Какой смысл в использовании шаблонизаторов?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Шаблонизатор шаблонизатору рознь. Но в целом следует выделить общие задачи. которые должны решать за вас шаблонизаторы. С blade не работал и не вижу смысла есть есть twig.

    Безопасность. Это пожалуй можно поднять на верх. Типичная картина в шаблонах на php - <?= $someUserInput; ?>. Частенько это можно встретить в выводе инпутов, при формировании ошибок поиска (мол "по запросу $userInput ничего не найдено. То есть вставляем в инпут подключение наших js скриптиков, если это форма поиска - делимся с "другом" и забираем его сессию. Ну или еще какие забавные штуки можно делать. А ведь все очень просто решается. Ставим какую-то функцию, которая по умолчанию будет фильтровать XSS инъекции при выводе, и не будет этого делать только если мы попросим. Если писать просто на php - появляются отвратные функции, которые можно просто забыть вызвать. А с шаблонизаторами мы пишем красивые {{ someUserInput }} и можем спать спокойно.

    Помогают соблюдать принцип DRY. Современные средства шаблонизации (twig например), предоставляют вам возможность разделять шаблоны на блоки, переиспользовать их несколько раз, выделять макросы, наследовать шаблоны... словом все что угодно. лишь бы вы могли реюзать куски html а не копипастить их.

    Ограничивают полет фантазии разработчика. Далеко не новость что разработчики ленивые засранцы. Особенно молодые. Если им в шаблоне внезапно понадобились какие-то данные из БД, или данные связанные с запросом, большинство не будет париться и зафигачит нужный код прямо в темплейте. Так же некоторые грешат тем что часть бизнес логики размазывают по шаблонам. Так же встречал проекты отданные на суппорт, где чуваки в шаблонах разбирали через xpath ответы от сторонней апишки (которая использовалась вместо базы данных. То есть это дело было размазано по всему проекту). Рефакторинг в случае изменения апишки будет болью.

    Хороший шаблонизатор должен настолько сильно усложинить вам процесс написания говнокода в шаблонах, что бы вы перехотели это делать и подумали как это можно сделать нормально. На выходе же мы имеем чистенькие шаблоны, которые ничего не знаю о бизнес логике приложения и знают только о логике отображения, чего мы и добиваемся вообще разделяя логику от представления. Это так же упрощает жить верстальщику (если он отдельно существует) или вам же в будущем при суппорте.

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

    Так как за все эти приятные вещи мы по сути ничего не платим (шаблонизатор должен компилировать все это в нативный php так что оверхэда просто не будет), почему бы не пользоваться?
    Ответ написан
    1 комментарий
    1 комментарий