• Почему я не могу закомментировать код html?

    SeaInside
    @SeaInside
    10 лет пилю все эти штуки
    Потому что синтаксис комментариев в HTML выглядят иначе. Вот так:
    <!-- Комментарий -->
    Ответ написан
  • Существует ли запрос типа WHERE `id` = `1`,`2`,`3`,`4`,`5` ?

    difiso
    @difiso
    В параллельной вселенной я космонавт
    А чем вас WHERE IN не устраивает?
    SELECT `name` FROM `user` WHERE `id` IN (1,2,3,4,5);

    Читать про SELECT в области
    In the WHERE expression, you can use any of the functions and operators that MySQL supports, except for aggregate (summary) functions. See Section 9.5, “Expression Syntax”, and Chapter 12, Functions and Operators.

    А потом всю статью Expression Syntax.
    Ответ написан
  • Существует ли запрос типа WHERE `id` = `1`,`2`,`3`,`4`,`5` ?

    deadbyelpy
    @deadbyelpy
    веб-шмеб
    есть конструкция WHERE IN
    SELECT `name` FROM `user` WHERE `id` IN (1,2,3,4,5);
    что альтернативно запросу
    SELECT `name` FROM `user` WHERE `id` = 1 OR `id` = 2 OR `id` = 3 ....
    Ответ написан
  • Существует ли запрос типа WHERE `id` = `1`,`2`,`3`,`4`,`5` ?

    Rsa97
    @Rsa97
    Для правильного вопроса надо знать половину ответа
    IN
    WHERE `id` IN ('1', '2', '3', '4', '5')
    Ответ написан
  • Vue.js, React или Angular? Express на Electron JS будет работать?

    @PavelPikat
    На Electron будут работать все фрейморки.
    Но мне кажется вам сначала нужно разобраться с чем, что и куда. Express - это веб сервер который крутится на удаленной машине и обрабатывает запросы пользователей по протоколу (например HTTP).
    Vue/React/Angular - в общем случае, это клиентские приложение которые работают локально в браузере пользователя.
    Electron - это обертка Хромиума, т.е. это десктопное приложение в основе которого лежит браузер.
    Соответвенно запускать веб-сервер внутри Electron это полнейшая глупость и не имеет никакого смысла.

    Имеет смысл резделить приложение на UI с Vue/React/Angular, которые могут работать на десктопе в Electron-приложении, и веб-сервер на Express, который должен работать на удаленной машине. Соответвенно клиентское Electron приложение может делать запросы к серверу и получать/отсылать данные и отображать их в своем UI.
    Ответ написан
  • Как браузеру прочесть минифицированный css файл?

    TTATPuOT
    @TTATPuOT
    https://code.patriotovsky.ru/
    HTML тоже можно минифицировать. Вопрос в скорости и в том, что сайт динамичный и каждый раз его нужно переминифицировать.

    CSS и JS скрипты могут быть минифицированными, это никак не влияет на работу браузера. Просто, код из типа:
    function test(num) {
      return 2 + num;
    }

    Становится менее читаемым для ЧЕЛОВЕКА, но более компактным:
    function test(t){return 2+t}

    Машине всё равно чё там читать, у неё нет чувств.
    Ответ написан
  • Как браузеру прочесть минифицированный css файл?

    @ar2rsoft
    PHP-developer
    Форматирование нужно только человеку, браузер прекрасно все прочитает.

    Html тоже можно минифициолвать, удалить пробелы, табудяции
    Ответ написан
  • Веб-разработка?

    @PxlFxr
    Прежде, чем стать веб-программистом, ты должен стать просто программистом, ты же не хочешь пополнить ряды многочисленных верстальщиков на реакте, или стать как "Веб-дизайнер, программист, креативщик, сценарист" из комментария выше?
    А чтобы стать программистом, начни изучать Computer Science в целом. Посмотри гарвардский курс CS50 , выписывай вопросы, которые не понятны, изучай дальше. Пока молодой, учи английский язык, очень пригодится. Постарайся поступить в хороший институт на специальность близкую к названию "Программная инженерия (Software Engineering)". Если у тебя будут хорошие базовые знания, то многие дороги будут открыты. Будет непросто, но если тебе это нравится, должно все получится.
    Ну и вот тебе еще хороший web developer roadmap 2019, там тебе на долго хватит.
    Ответ написан
  • Где найти начинающих веб разработчиков для совместной работы над образовательным проектом?

    alex-1917
    @alex-1917
    Если ответ помог, отметь решением
    Я согласен — и впредь не платите, 
    Пусть шатает меня на ходу, 
    Не давайте жилья, не кормите, 
    Всё равно на работу приду. 
    
    День получки — нет траурней даты, 
    Просто нет её в этом году, 
    Не давайте паёк и зарплату, 
    Всё равно на работу приду. 
    
    Отдыхать ни за что не поеду, 
    Это море имел я (в виду), 
    Чай пустой и сухарик к обеду, 
    Всё равно на работу приду. 
    
    И лечиться мне вовсе не надо, 
    Могут вылечить вдруг на беду, 
    Не нужны никакие награды, 
    Всё равно на работу приду. 
    
    Ничего, что одежда в заплатах, 
    Я не вру Вам, имейте в виду, 
    Даже если проезд будет платным, 
    Всё равно на работу приду.
    Ответ написан
  • Развитие разработчика. Интересная работа или деньги?

    JhaoDa
    @JhaoDa
    LaravelRUS Team
    Нам-то откуда знать, какие у тебя приоритеты? Вдруг ты на яхту как у Усманова хочешь заработать. Если с деньгами нет проблем, то можно отдать предпочтение интересной работе.

    Я выбираю интерес, потому что сидение на неинтересной, но стабильной работе в душевном коллективе однажды уже привело к увольнению с конфликтом, повторять не хочется.
    Ответ написан
  • Как выложить проект на vue.js на хостинг?

    @ianbrode
    А чем проект генерировал? Если vue-cli то запусти npm run build и потом положи на хостинг содержимое папки dist.
    Ответ написан
  • На чем зарабатывает Quora, toster или подобные сайты?

    shmatuan
    @shmatuan
    8 year of Web, 5 years of Vue
    Можно просто выключить адблок и увидеть ответ
    5bd0447166cd2277435374.png
    Ответ написан
  • Хочу сделать API, с чего начать?

    zoonman
    @zoonman
    CEO @ LinuxQuestions.ru
    Следует начать с проектирования API. Возмите https://swagger.io/ и набросайте все, что нужно.
    Swagger вам позволяет объединить роутинг, документацию и примеры вызовов в единое целое.
    Кроме этого он позволяет сгенерировать заглушки для разных языков программирования и фреймворков.
    В принципе вы можете найти значительное количество интеграций для разных фреймоворков.

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

    В REST есть 6 принципов, прекрасно изложенных в Wiki. В REST нет ничего сложного и особенного. Это просто надстройка над стандартным протоколом HTTP. Именно поэтому нет никаких особенных уроков. Изучите работу HTTP и вы поймете как работает веб в целом и REST в частности.

    По поводу отдельного сервера для API. Есть множество разных подходов. В последнее время все более актуальными становятся Serverless-приложения. Serverless архитектура идеально вписывается в REST. Но думаю для вас это пока рановато и сложновато. Слишком много для начала.

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

    По поводу best practices есть очень хороший ресурс https://12factor.net/ru/
    Он в целом применяется для всех приложений.

    Запомните: первый блин всегда комом. Прочитайте все ресурсы, которые я привел для вас. В них много ссылок на другие, походите по ним, присмотритесь. Напишите первую версию API так, как вам кажется удобно. Постарайтесь применить практики из статей.
    Вам нужен опыт и вы его не наберетесь, пока не сделаете что-то сами. Вы можете потратить год на чтение, но останетесь на том же месте, с которого начали. А другой человек напишет на коленке API за неделю, а потом перепишет его 20 раз за год и он вам расскажет в 10 раз больше, чем то, что вы изучили за год.
    Дерзайте!
    Ответ написан
  • Верстка с нуля: какие основные этапы работы?

    Vlad_IT
    @Vlad_IT Куратор тега Вёрстка
    Front-end разработчик
    Использую vscode+webpack+pug+scss+бэм. Из физических инструментов, основной моник: lg ultrawide 29um69g, рядом прикручен моник от ноутбука повешенный вертикально, подключенный через универсальный скаллер.

    0) Запускаю Spotify :-)

    1) Произвожу установку всех необходимых модулей для сборки. В моем случае у меня набор конфигураций для webpack (отдельные файлы для pug, scss, static и.т.д., выбираю что нужно).

    2) Запускаю avocode, загружаю в него макет. Определяю в нем переменные (в то же время записываю их, чтобы сразу кинуть в scss файл) для цветов, размеров шрифтов и.т.д. чтобы при получении кусочков кода из него, он сразу расставлял переменные.

    3) Запускаю VS Code, открываю нужную папку.

    4) Пишу размету на Pug. Пишу с БЭМ, если встречаю повторяющийся блок, то открываю файл _mixins.pug, в который пишу миксины для повторяющихся блоков, например товаров, пунктов меню, каких-то блоков и.т.д. Pug умеет делать циклы, это ускоряет сильно.

    5) Когда HTML готов, начинаю делать каркас. Если дизайн сделан по сетке, определяю контейнеры, колонки, строки в свои классы (не пишу в html тучи классов аля col-md-6, а пишу в SCSS инклуды в нужные мне блоки, типа @include make-col(2) и.т.д.).

    6) Экспортирую картинки из Avocode. Очень делается просто, указываю папку и просто кликаю экспорт и ввожу название файла и расширения. Преимущественно для иконок использую svg, если нет svg, то ищу эту иконку в интернете (дизайнеры редко рисуют иконки сами, но зато любят вставлять их не в векторе). Если иконка простая, могу сам ее в inkscape обвести, ну и если нет, то экспортирую png в размере (благо авокод это позволяет, если конечно дизайнер не вставил в исходном маленьком размере). Когда есть контакт с дизайнером, трясу его, ибо растр это плохо для иконок.

    7) Пишу стили блоков из страницы. На этом этапе можно на втором монике параллельно смотреть футураму или
    Арчера :-) Но чаще на широком монике слева браузер, справа VS Code, а на втором монике Avocode (может меняться местами с браузером). Мысленно нарезаю страницу на блоки. Для каждого блока (БЭМ) создаю отдельный scss файл (кто-то даже для элемента создает, но мне лень), из него сразу выписываю все селекторы. Иногда могу сначала выписать все селекторы со страницы (но так лучше не делать, т.к. во время работы может потребоваться изменить что-то в разметке), но чаще для одного блока выполняю этот пункт и за ним сразу выполняю пункт 8, потом для нового блока опять 7 и 8 и.т.д.

    8) Пишу css код вместе с Avocode, у него беру нужные мне параметры (а он уже подставил в них переменные), и вставляю в мой код. И параллельно сверяю со скрином макета используя вот это расширение https://chrome.google.com/webstore/detail/perfectp...

    9) Пишу адаптив. Я не могу привыкнуть к методологии mobile-first, поэтому пишу всегда сначала полную версию сайта. Я понимаю, что это чревато всякими проблемами и это типа не модно, но мне норм.

    10) Медиа-запросы пишу прямо в блоках, для каждого блока/элемента/модификатора может быть отдельный медиа-запрос. Но для начала определяю breakpoint'ы для разных экранов (чтобы их не было сотни разных), если использую Bootstrap, то беру его breakpoint'ы.

    11) Добавляю анимашки. Даже если заказчик не просил отдельно (и если не указал отдельно, что нельзя), он все равно будет доволен, а с animate.css+onscreen.js это вообще работа 10 минут. Сложные анимации обговариваю отдельно, чтобы не сделать ненужную работу.

    11) Все снова сверяю, пишу скрипты где надо. Для слайдеров в 99% случаев подходит slick (с доработками конечно, но там хорошее API), для других случаев могу написать свой.

    12) Сдаю заказчику и жду ответа сидя на тостере/пикабу.

    Это чисто мой опыт, опыт фрилансера, не знаю, как делают другие и не могу на 100% утверждать что это 100% правильный способ. Я так и не смог заставить свой конфиг webpack правильно вставлять спрайты svg.
    Надеюсь чем-то поможет мой ответ.
    Ответ написан
  • Обязательно ли использовать какой-либо фреймворк?

    27cm
    @27cm
    TODO: Написать статус
    Если проект будет активно развиваться, то без фреймворка не обойтись. Но давайте попробуем рассмотреть поближе разные варианты.

    1. Использование готового фрейморка, с которым вы уже работали
    Если фреймворк достаточно популярный и вы хорошо с ним знакомы, то есть работали несколько лет, знаете его возможности, сильные и слабые стороны, то такой фрейморк позволит существенно ускорить разработку проекта, особенно на начальной стадии. Под такой фрейморк уже наверняка написаны готовые модули, которые позволят ещё сильнее упростить разработку. С хорошим фреймворком первую версию готового проекта можно написать меньше, чем за неделю.

    Но будьте готовы к тому, что выбранный фреймворк станет самой большой зависимостью в вашем проекте. Если через несколько лет вы решите сменить фреймворк, по трудозатратам это будет примерно равносильно смене языка программирования для проекта. Причины сменить фреймворк бывают самые разные: фреймворк устарел, не удается найти специалистов с опытом работы на данном фреймворке; фреймворк прекратил развиваться; фреймворк сильно замедляет работу приложения; возможностей фреймворка перестало хватать, а написание собственных модулей требует больших временных затрат.

    2. Использование готового фрейморка, с которым вы никогда не работали
    Готовьтесь потратить массу времени на его изучение. Порой даже на решение тривиальных задач в некоторых фреймворках придется потратить несколько дней, если вы с этим никогда не работали. По собственному опыту могу сказать, что если сравнивать варианты (2) и (4), то готовьтесь потратить в 3 — 4 раза больше времени. Однако у этого варианта есть и плюсы: вы освоите ещё один фреймворк и в следующих проекта сможете выбирать вариант (1), другим разработчикам знакомым с данным фреймворком будет гораздо проще разобраться в коде, последующая разработка и развитие проекта существенно ускорятся.

    3. Использование собственного фреймворка
    Рекомендуется только строго после того, как вы несколько лет поработали с разными фреймворками, точно знаете их недостатки, четко можете сформулировать, почему в данном проекте не подходит ни одно из готовых решений. Плюсов у такого решения масса, но основной — ваш фреймворк будет оптимальным образом решать именно ваши задачи, он не будет «комбайном», пытающимся угодить всем вокруг. Но и минусов хватает, крупные фреймворки как правило развиваются огромным сообществом, сотни и тысячи разработчиков ежедневно находят и исправляют в нем ошибки, расширяют функциональные возможности, улучшают производительность, заменяют устаревшие решения на новые.

    4. Вообще без фреймворка
    Такой проект сильно рискует превратиться в спагетти-код. Но абсолютное большинство новичков начинает именно с этого. В этом нет ничего страшного, если это ваш первый проект, вы освоитесь с языком и его возможностями, набьете кучу шишек, и неизбежно рано или поздно перейдете к вариантами (1), (2) или (3).
    Ответ написан
  • Зачем использовать template engines(pug, handlebars и т.д.) если есть ui libraries(react, vue)?

    @account-6
    Для начала Реакту и Вью пару лет от роду (активного использования и хайпа).

    И темплейтинг - это какой-то жалкий процент от их возможностей.

    Вопрос некорректный. Для использования pug, handlebars достаточно одного модуля. Для Реакта нужно поднимать целое окружение (для того чтобы нормально использовать). Со вью проще, но для получения выгоды темплейтинга тоже одного Вью не хватит, нужна сопутствующая экосистема (vue-loader как минимум). И с тем же vue-loader спокойно используют и Jade.

    687474703a2f2f626c6f672e6576616e796f752e

    Вообщем, ты сначала бы сам попробовал все, судя по вопросу понимание весьма расплывчатое.
    Ответ написан
  • Зачем использовать template engines(pug, handlebars и т.д.) если есть ui libraries(react, vue)?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Я бы не стал так все в одну кучу валить.
    pug — это не только шаблонизатор, но и препроцессор, то есть он предоставляет альтернативный, во многом удобный синтаксис.
    Для vue/react генерация html это только часть обязанностей, они еще должны аккуратно и быстро обновлять его и реагировать на пользовательский ввод.
    Если проект не предусматривает динамического фронтенда, то вполне можно обойтись одним шаблонизатором — pug/handlebars/что хотите. Далеко не везде нужен SSR.

    P.S. то, что react нельзя использовать с pug — это личные половые трудности сугубо реакта. Я использую vue+pug и доволен как слон:)
    Ответ написан
  • Какую ширину сайта рекомендуется делать в 2016 году?

    Serj-One
    @Serj-One
    i'm sexy and i know it
    Нужно понимать, что ширина сайта (именно контентной части) должна зависеть не от ширины монитора пользователя, а от удобства восприятия. Бегать глазами от одного угла экрана к другому пользователю попросту неудобно. Оптимальное решение - прежние максимальные 1200px для десктопа, и адаптив до 320px.
    Ответ написан