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

Jim

Лайки

  • Как правильно верстать PSD-макет c шириной 1663px или Какими должны быть требования к макетам для дизайнеров?

    Ronnie_Gardocki
    @Ronnie_Gardocki
    Я у мамы фронтендщик.
    Сверстать сайт с шириной в 1600 пикселей не проблема. Проблема сделать так, чтобы контент хорошо было видно на десктопах с более низкой шириной, аля 960-1300, имея всю ту же pixel-perfect верстку. Просить отдельный макет для мелких десктопов - мертвый номер, ибо почти никто не будет над таким париться. Делать примитивную резину для десктопа - выбор для тех, кого устраивает клепание говносайтиков. Ибо на сайтах с нормальным дизайном важно сохранение пропорций, 2015 год все таки.
    Я сейчас пилю фронт-енд для китайского интернет-магазина, у которого все десктоп макеты 1800px шириной. При этом им важно, чтобы на каком-нибудь ноутбуке с 1376x768 все выглядело так же, но при этом влезало. В итоге делаю все в rem юнитах. 1800 пикселей стартовая точка, где html, body {font-size: 125%;}, то есть 1rem = 20px (о том, почему не 62.5% для 1rem=10px, напишу ниже). Далее, через media-queries, снижаясь на каждые 10% от ширины, уменьшаю font-size на 10% (то есть на 12.5% в нашем случае). И так вплоть до 1.1к пикселей, то есть почти самого низкого десктопа. Заказчик в восторге, все выглядит ровно так как ему надо на всех разрешениях во всех браузерах (ему естественно не нужен убогий ie8).
    По поводу font-size: 125% - я изначально делал 62.5%, но при понижении до 40%- font-size (аля ~1300px) вебкитовские браузеры на MacOs начинали считать что такая величина шрифта слишком мала для юзера и сами по своей воле рандомно увеличивали габариты элементов. Увеличив весь font-size вдвое, проблема изчезла.
    Ответ написан
    7 комментариев
    7 комментариев

  • Почему не все серверы пишутся на Node js?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
    Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

    2. Ответ на абстрактный вопрос:
    а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
    б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
    в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

    UPD
    hbrmdc
    У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
    Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

    1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
    JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

    На самом деле основные отличия другие:
    Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

    2) Личные предпочтения обоснованные привычками это основной аргумент.
    Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
    Мне нужна новая команда на новый проект.
    Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
    PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
    Собственно на этом выбор и закончен.

    На малопопулярных языках пишут в случаях:
    a) это мелкий сервис с неявными перспективами который можно переписать за неделю
    б) это проект "для души" разработчика.

    Получается замкнутый круг на самом деле.
    Менеджер смотрит резюме, резюме на node.js нет =>
    Менеджер не начнет проект на node.js =>
    Не возникнет вакансия на node.js =>
    Разработчик анализируя вакансии не увидит вакансий на node.js =>
    Разработчик будет учить что то другое =>
    Менеджер смотрит резюме, резюме на node.js нет...

    Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)
    Ответ написан
    13 комментариев
    13 комментариев

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

    Serj-One
    @Serj-One
    i'm sexy and i know it
    Кусок моего галпфайла. Что-то снабдил комментами.
    var connect      = require('browser-sync'); // livereload
var sass         = require('gulp-sass'); // Кому что, я использую SCSS
var csscomb      = require('gulp-csscomb'); // Обязательно!
var cssmin       = require('gulp-cssmin');
var imageop      = require('gulp-image-optimization'); // Лучшая альтернатива gulp-imagemin
var concat       = require('gulp-concat');
var uglify       = require('gulp-uglify');
var plumber      = require('gulp-plumber'); // Не позволяет плагину умереть молча
var autoprefixer = require('gulp-autoprefixer');
var ngrok        = require('ngrok'); // Пробрасываем локальному серверу путь наружу для для заказчика
var spritesmith  = require('gulp.spritesmith'); // Спрайты
var notify       = require('gulp-notify'); // Уведомления
var merge        = require('merge-stream'); // Деление таска на разные потоки

    Конечно, есть много полезного и кроме этого. Но сам верстаю в WebStorm, в котором огромное количество плюшек реализованы куда удобней, чем в галп-плагинах.
    Ответ написан
    8 комментариев
    8 комментариев

  • Flexbox и колоночная сетка?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    flexboxgrid.com
    Ответ написан
    Комментировать
    Комментировать

  • Gulp - gulp-stylus + gulp-concat = любовь?

    SanDiesel
    @SanDiesel
    HTML CSS JS
    Не городите слишком сложных задач, это системе выполнять не легче. чем вам потом поддерживать. Советую пойти путем, многими уже принятым: 1) создаете задачу по перегону styl в css с выходом одного файла в каталог build 2) создаете задачу с конкатинацией всех сторонних css тоже в каталог build 3) на третью задачу вешаете конкатинацию всех css из каталога build и делаете с ними уже все операции, минификация, автопрефиксы и тд. Для того чтобы первые две задачи выполнялись до выполнения третьей, третью задачу можно описать как 
    gulp.task('task3', ['task1', 'task2'], function() {
  // Код третьей задачи
});
    Ответ написан
    13 комментариев
    13 комментариев