• Какие технологии вы используете для лендингов?

    Nikolay12
    @Nikolay12
    Верстальщик
    Если без фреймворка, а просто верстка по макету, то:
    • Emmet - быстрый кодинг html и сss
    • less - переменные для шрифтов, вложенность селекторов или бэм-нейминг.
    • flexbox - для сетки, расположения элементов и респонсива.
    • autoprefixer - добавление css-префиксов
    • Imagemin-pngquant - для сжатия картинок
    • gulp - для сборки вышеперечисленного
    • slick - карусели и слайдеры
    • remodal - модалки


    Если использовать фреймворк, например, bootstrap, то быстрее будет работать с исходниками бутстрапа и потом собрать их:
    • переопределить переменные
    • подключить нужные js-скипты из коробки
    • подключить нужные less-стили
    • собрать это всё галпом
    Ответ написан
    1 комментарий
  • Как уйти от использования jQuery?

    Sanasol
    @Sanasol Куратор тега JavaScript
    нельзя просто так взять и загуглить ошибку
    Искать альтернативы на каждую нужную функцию...
    youmightnotneedjquery.com

    Правда может так быть что альтернатив наберется больше чем jQuery и смысл потеряется.

    Опять же для лендингов всяких и т.д. вполне нормально использовать, чтобы экономить время.
    Тем более что всякие плагино-расширения в основном под jQuery.

    Сам вот буквально вчера выпилил jQuery который был просто по привычке в очень маленьком коде.
    И из всего jQuery использовался только ajax()
    В итоге заменил ajax на нативный request.
    Экономия 85кб кода, не говоря уже про процессорное время клиентов.

    Но эта дурная привычка все еще не отходит.
    Сам код 200 строк и один ajax вызов. Ради этого тянул jQuery, видимо обкурился когда делал xD

    В самом по себе jQuery ничего плохого нет.
    Главное не использовать вот как я выше написал.

    UPD:
    Минифицированная версия последней jQuery весит 84 кб. Читабельность выше.
    Чем же лучше натив?


    Может быть тем что ради одной строчки вы не тянете 84кб кода, который между делом загружается в память клиентам, выполняется,и кушает ресурсы?
    Ответ написан
    Комментировать
  • Webpack годится в продакшн?

    maxfarseer
    @maxfarseer
    https://maxpfrontend.ru, обучаю реакту и компании
    Добрый день, как уже было сказано выше - задача webpack'a собрать файл (со стилями и js, или только js), который называется в общем случае "бандл". Для этого, бандл нужно собрать (сделать билд) с помощью production конфига для webpack. Продакшен конфиг обычно включает в себя различные "штуки" для оптимизации конечного размера бандл файла, ведь чем меньше - тем лучше.

    Далее бандл вы выкладываете к себе на сервер и отдаете как обычный статичный файл. В таком случае, после изменений кода, вы должны будете:
    а) заново сделать билд (собрать новый бандл)
    б) перезаписать файл на сервере

    Обычно в проекте есть 2 конфига: dev (девелоперский, то есть конфиг удобный для разработчика) и prod (конфиг, в котором главное - пожать файл как можно сильнее).

    В dev конфиге, например, часто используют webpack-dev-server, который позволяет пользоваться такой штукой как HMR (hot module replacement), которая в свою очередь позволяет очень комфортно разрабатывать: вы изменяете что-то в файле, и у вас сразу в открытом окне браузера отображаются изменения (без перезагрузки страницы).

    В prod конфиге такое конечно не нужно.

    Пример команды, для того, чтобы сделать prod бандл:
    NODE_ENV=production webpack --progress --config ./webpack.prod.config.js -p


    Главное здесь -p, так как эта опция говорит вебпаку, что необходимо сделать продакшен-сборку. Так же, в этой команде указан специальный конфигурационный файл (webpack.prod.config.js) и переменная NODE_ENV имеет значение 'production'

    Поэтому, точнее будет ответить: с вебпаком можно собрать файл скриптов (и, если настроено, стилей) для продакшена.
    Ответ написан
    Комментировать
  • Стоит ли использовать Angular2 с ES6?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Собственно могу ли я обойтись ES6 при работе с Angular


    Можете, вопрос в рациональности.

    Хоть код на TS отличается не сильно, он все же отличается. А так как большая часть учебных материалов по ангуляру все же будет на TS - то стоит задуматься. Да и не так плох TS.
    Ответ написан
    Комментировать
  • Как правильно создать структуру приложения на ReactJS + Laravel 5.3?

    На бэкенде: делаете rest-api с помощью Laravel.
    На фронтенде: берете реакт + редакс и разрабатываете приложение, которое будет общаться бэком через АПИ.
    Ответ написан
    Комментировать
  • Как правильно вести разразработку в PhpStorm?

    greabock
    @greabock
    Могу
    Правильно - использовать систему контроля версий. Например git.
    Если совсем правильно, то для деплоя нужно использовать, соответствующий инструмент (например Capistrano или любой другой аналог)
    Для бедных, можно настроить банальный хук.
    При пуше (или мерже) допустим в мастер, на рабочий сервер улетает хук. Обработчик хука в свою очередь стянет все изменения из репозитория системы контроля версий, и запустит все необходимые команды (миграции, прогрев кеша, и вообще всё, что душе угодно).
    Ответ написан
    Комментировать
  • Как эффективнее всего изучать yii2?

    @vkdv
    Прости что лезу не в свое дело, но мое мнение, что yii2 лучше вообще не изучать. Изучай Laravel/Symphony etc

    Приведу несколько аргументов (в сравнении с laravel):

    1) Yii2 довольно слабо следует принципам SOLID и более того, не предоставляет в достаточной мере архитектурного решения разработчику, чтобы он сам им следовал
    2) Yii2 Костылен, а его исходники мягко говоря не очень. Например behaviors (костыль) против middlware(прозрачное решение)
    3) Yii2 Имеет устаревшие сервисы из коробки относительно Laravel , который развивается куда более активно.
    Помимо прочего в Laravel намного больше готовых сервисов (Elixir , scheduling, Queue , Blade, Storage, Broadcast , Notifications) Вместо этого в yii2 есть только bower assets - который представляет с собой дикий костыль и откровенно ужасен, да еще и не безопасен, а также вроде в yii2 есть сервис для работы с файловой системой, но я с ним не работал. Остальные сервисы типа bootstrap , console etc есть и там и там
    4) Магия Yii2 не способствует контролю за кодом и прозрачности
    5) Yii2 имеет довольно плохо продуманную архитектуру, о чем говорит например тот факт, что jquery вшит в ядро фреймворка (возможно и некоторые другие ассеты) и это очень странно. Особенно когда тебе нужно запускать консольные приложения
    6) ActiveRecord в yii2 доволбно запутан, по сравнению с https://laravel.com/docs/5.3/queries (кончено это субъективно)
    7) Yii2 не особо популярен в мире, у него плохая документация и я думаю он серьезно отстоет от конкурентов.

    Есть конечно у него и плюсы, например он быстрее laravel и у него есть поддержка модулей(что решается в laravel подключением пакета)
    Ответ написан
    9 комментариев
  • Как эффективнее всего изучать yii2?

    slo_nik
    @slo_nik Куратор тега Yii
    Добрый день.
    Читать документацию, смотреть проекты на github, пытаться написать своё решение для какой-либо задачи....
    Вот несколько ссылок, которые Вам помогут:
    1) rmcreative.ru (блог одного из разработчиков yii2)
    2) https://github.com/samdark/yii2-cookbook (рецепты от того же разработчика)
    3) www.elisdn.ru/blog/tag/Yii2 (один из блогов, где можно учиться работать с yii2)
    4) https://github.com/yiisoft/yii2/tree/master/docs/g... (документация на русском от разработчиков yii2)
    Ответ написан
    1 комментарий
  • Есть ли ляпы в коде?

    In4in
    @In4in
    °•× JavaScript Developer ^_^ ו°
    Одна логическая ошибка в коде точно есть. Объясню ее на примере.

    function setHandler(el){
    
       var obj = new MyController(el);
    
      $(el).on("click", function hand(){
          alert(obj.name);
      });
    
    }
    
    setHandler(element1);
    setHandler(element2);


    После выполнения данного кода в память браузера попадают:
    • Функция setHandler
    • Два объекта типа MyController
    • Две функции hand - обработчики события onclick.


    Да-да, для каждого вызова setHandler создается своя функция hand. Две (три, десять или даже миллион) разные функции с одинаковым телом. Все, что их отличает - область видимости, в которой они объявлены (к примеру, внутри каждой из них доступен свой obj).

    Но, спрашивается, как мы можем оптимизировать потребление памяти в данной ситуации? А вот так:

    function hand(){
    
      var obj = $(this).data("obj");
    
      alert(obj.name);
    
    }
    
    function setHandler(el){
    
       var obj = new MyController(el);
    
      $(el)
        .data("obj", obj) //Как вариант
        .on("click", hand)
      ;
    
    }
    
    setHandler(element1);
    setHandler(element2);

    Вынесем hand в более высокую область видимости.

    Теперь в памяти сохранены:
    • Функция setHandler
    • Функция hand
    • Два объекта MyController
    Ответ написан
    7 комментариев
  • Есть ли ляпы в коде?

    sfi0zy
    @sfi0zy Куратор тега JavaScript
    Creative frontend developer
    Комментарии в коде бесполезные, только глаза мозолят:
    index: function (settings) {
        // Метод контроллера index
    ....
    create: function (settings) {
        // Метод контроллера create
    ....

    Если уж вы описываете свой код - делайте это с умом, посмотрите какие есть средства для генерации документации, например JSDoc

    Используйте фигурные скобки и отступы везде, где только можно. Я, разумеется, понимаю, что "стильно модно молодежно" писать if в одну строку, но такого рода конструкции взрывают мозг:
    ....
    else data = settings;
    if (typeof data !== "string") data = $.param(data);
    if (method == 'post') return $.post(url, data + '&_method=' + method_hidden);
    else return $.get(url, data);
    ....

    И, если еще придираться, - пустые строки после объявления переменных, после if/else, и.т.д. улучшают читабельность.

    Не используйте ключевые слова из es6 где попало:
    class: '.jsgrid-container',

    Есть некоторая непоследовательность - иногда вы выносите объявления всех переменных в начало функции, иногда нет. Имеет смысл определиться и использовать что-то одно.

    Да, и киньте ссылку на codepen что-ли, а то в 500 строк кода ни разу не понятно работает ли там что-то (и что оно вообще делает). И к этому хочется добавить - посмотрите в сторону систем сборки (Grunt/Gulp/...)на ваш вкус - скорее всего эти 500 строк можно разбить на части поменьше, станет проще ориентироваться в происходящем.
    Ответ написан
    1 комментарий
  • Лучшие книги для изучения JavaScript в области разработки интерфейсов (Frontend)?

    evgeniy8705
    @evgeniy8705
    Повелитель вселенной
    Для чего составлять такую подборку? Вы просто перечислили практически все книги на русском по JS. При чем однотипные.
    Большинство из них описывают одно и тоже. Я прочитал почти все из этого списка. По опыту могу сказать, что читать всю подборку не нужно.
    Посоветовал бы прочитать книгу Ильи Кантора и книгу "Javascript для профессиональных веб-разработчиков", автор Николас Закас вроде.(Вместо второй можно прочитать Фленагана. Подробное руководство., но Заказ мне больше нравится, по моему мнению гораздо лучше объясняются многие вещи). Две эти книги, достаточно объемные и информативные, всю основу прекрасно преподносят.
    Также посоветовал бы книгу по оптимизации производительности, автор также Николас Закас и любую книгу по регулярным выражениям, но это уже после некоторой практики. А также книгу "Веб-приложения на JavaScript". Сам ее только вот начну читать, но по содержанию и отзывам достаточно хорошая.

    Достаточно будет чтобы довольно хорошо освоиться в языке.
    Не нужно читать однотипные книги. С 3 по 6 включительно пункты не стоит читать. Только зря потратите время.

    ООП объясняется в первых двух книгах которые я упомянул. Также книга про паттерны - largescalejs.ru/.

    Но главное не просто читать а повторять все примеры и выполнять все задания, попутно придумывания задания для себя самому. Чем больше практики, тем лучше будет откладываться информация в голове и будет намного лучшее понимание что да как.
    Я читать некоторые книги по несколько раз, потому что не сильно парился сначала о практике, просто читал, выполнял некоторые задания, по ходу было понятно, но через главу, уже все забывалось... Поэтому практикуйте, практикуйте и еще раз практикуйте.
    Удачи в обучении!
    Ответ написан
    Комментировать
  • Какие плагины использовать веб разработчику в sublime text 3?

    Может быть немного не по теме, но я долго использовал Sublime, а потом перешёл на PHPStorm и теперь работа в Sublime это боль и одни неудобства. Так что советую перебраться или хотя бы попробовать. А так у меня стоял Emmet, Git и CodeIntel.
    Ответ написан
    8 комментариев
  • GIT как правильно пользоваться?

    @xfg
    Github Flow за 5 минут.

    1. Создал ветку для фичи/фикса
    2. Сделал в ветку несколько коммитов
    3. Отправил пулл риквест
    4. Обсудил с коллегами пулл риквест и при необходимости внес правки
    5. Прогнал ветку через тесты.
    6. Влил в master
    7. Выкатил master на продакшн

    Если фича ветка долго не мержится и начинает расходиться с master веткой, то вливаем master в фичу ветку и продолжаем.

    Если кто-то из команды хочет руками потестить новую фичу, то может сделать
    git checkout -b new-feature origin/new-feature
    И потестить руками локально на своей дев машине.

    Update: Если sql база, то пишут миграции. Можно посмотреть в любом фреймворке что это и как использовать. После каждого git pull пробуем накатить миграции через консоль (можно хук для гита написать) и если есть новые миграции, то они применятся к локальной базе. Если nosql база типа mongo, то ничего не надо, они schemaless.

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

    • www.nczonline.net
    • 2ality.com
    • ponyfoo.com
    • mathiasbynens.be
    • davidwalsh.name
    • rmurphey.com/archives
    • caolan.org
    • perfectionkills.com
    • www.bennadel.com
    • addyosmani.com/blog/
    • dmitrysoshnikov.com
    • yehudakatz.com
    • ncombo.wordpress.com
    Ответ написан
    3 комментария
  • Как организовать "архитектуру" верстки проекта (верстать модульно)?

    iscareal
    @iscareal
    Front-End Developer
    У меня структура выглядит вот так:
    e73c40d360ae47538ed55bc57f684c85.pngstyles.scss
    // Тут подключение всех бутстрап компонентов, если используется этот фреймворк.
    
    // Helpers
    @import "helpers/variables";
    @import "helpers/mixins";
    
    // Vendor (Вендорные стили. Например от плагинов)
    @import "../../node_modules/slick-carousel/slick/slick.scss";
    
    // Common (основные стили.)
    @import "common/base";
    @import "common/typograpy";
    
    // Components (мелкие визуальные элементы)
    @import "components/buttons";
    @import "components/forms";
    @import "components/loader";
    @import "components/table";
    
    // Modules (большие куски. Шапка, футер, продукт)
    @import "modules/footer";
    @import "modules/header";
    @import "modules/main-slider";
    @import "modules/navbar";
    @import "modules/section";
    @import "modules/services";
    
    // Pages (стили, котрые нужно применить для конкретной страницы)
    @import "pages/index";


    Такая структура позволяет подключать компоненты, модули и стили страниц в алфавитном порядке, что делает удобным поиск подключения того или иного файла
    Ответ написан
    2 комментария
  • Зачем тестировать код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Что тут тестировать и зачем? в случае неудачи получим исключение. Названия колонок мы знаем. Данные в контроллере валидируются.


    вы должны проверять корректность работы системы. Всего-то. Причем с оглядкой не только на "сейчас" (тут мы и руками можем проверить быстро) но еще с оглядкой на будущее. Если вы планируете этот код выкинуть - тестировать его нет смысла. Вы на автоматизацию тестирования убьете больше времени чем проверите руками.

    С другой стороны, если это лишь вершина айсберга, то имеет смысл написать простенький автотестик, который проверяет корректность работы. Так, если мы будем вносить какие-то изменения, например будем добавлять комменты, мы будем уверены на 90% что ничего не сломали. Почему не на 100%? потому что невозможно покрыть все тестовые сценарии да и это не выгодно. Проверяем мы обычно самые вероятные сценарии.

    Далее уже все зависит от сложности тестирования. По хорошему наши тесты должны быть маленькие и, главное, ничего не знать о деталях реализации. Скажем вы хотите проверить что система корректно добавляет новости. Самый простой способ это проверить - создать новость и проверить что не вернулись ошибки. Для этого можно составить HTTP запрос и получить HTTP ответ. Максимально просто.

    Но такой тест отрабатывает относительно долго. Представьте себе что вы пишите что-то посложнее. И у вас уже 100 различных тестовых сценариев для одого кусочка системы. В итоге этот маленький кусочек будет тестироваться больше минуты, и мы успеем заскучать. Для того что бы упростить - мы дробим этот кусочек еще и еще пока не находятся такие куски, которые мы можем проверить удобно и быстро. Например если вопрос в корректности валидации данных - мы можем тестировать только контроллер, а если вопрос в каких-то бизнес правилах отдельных - мы можем и их отдельно вынести и тестировать. Это будут интеграционные тесты.

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

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

    По сути это самое сложное в тестировании. Писать тестируемый и поддерживаемый код, а так же останавливать себя от тестирования "лишних" частей системы или слишком углубляться в тестирование там где этого не нужно.
    Ответ написан
    1 комментарий
  • Какие есть обучающие материалы по React на русском?

    SPAHI4
    @SPAHI4
    реактовцы - это не девы, а прокидыватели пропсов
    Ответ написан
    Комментировать
  • Какие есть обучающие материалы по React на русском?

    @Alex493049469
    Ответ написан
    Комментировать
  • Качество кода в компонентах битрикса?

    kumaxim
    @kumaxim
    Web-программист
    Предстоит редактирование достаточно крупного интернет магазина

    Вы ящик водки уже купили?
    Ответ написан
    1 комментарий
  • Почему на production не рекомендуют использовать систему контроля версий?

    ppokrovsky
    @ppokrovsky
    Нет такого, что рекомендуют или не рекомендуют. Все зависит от вашего проекта. Те доводы, которые здесь перечислены насчет CI итд - правильные. Дополнительным аргументом в пользу deploy-скриптов может быть, например, необходимость изменения схемы БД на проде с очередным апдейтом, чего git не сделает сам по себе. Плюс, обновление через git - не очень рабочий вариант в случае компилируемого кода. Конечно, можно навернуть поверх гита каких-нибудь билдеров, но этому уже точно на проде не место.

    Но если, например, проект простой, компилируемого кода нет, и в команде есть договоренность о том, что в master попадает только протестированный код, то никакого криминала в том, чтобы сделать git pull, нет.
    Ответ написан
    Комментировать