Контакты

Достижения

Все достижения (17)

Наибольший вклад в теги

Все теги (60)

Лучшие ответы пользователя

Все ответы (168)
  • Как вы организуете свою работу?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    Про GitHub.

    1) Любой проект, даже самый маленький начинаю в новом репозитории. Потому что:
    - мало ли что из него вырастет,
    - код в Гитхабе это бэкап, не засерается место в Дропбоксе или других облаках,
    - мгновенный поиск по коду в репозитории, актуально когда проект уже достаточно большой,
    - легче спросить совета у коллег или показать проблему, когда исходники можно посмотреть онлайн,
    - проект удобно хоронить, если он заглох, или закинуть в портфолио, если он клевый.

    2) Создал себе на Гитхабе две дополнительные организации внутри своего аккаунта.
    - «paulradzkov-forks» — для форков чужих проектов.
    - «paulradzkov-heaven» — кладбище для старых проектов, куда перемещаются все неактуальные проекты.
    Эти две дополнительные организации позволяют очистить основной аккаунт от мусора. В нем теперь только несколько актуальных проектов, в которых легко ориентироваться.

    3) Перемещаю все старые проекты из Дропбокса на Гитхаб в «paulradzkov-heaven». Проектов много, это долго, но освободилось уже несколько гигов (т.к. там кроме кода psd-исходники, архивы с инсталляторами и прочее). Место в облаках заканчивается, а на Гитхабе — резиновое.
    Это кладбище уже пригодилось, когда у меня попросили поискать исходники проекта, над которым я работал 3 или 4 года назад, а я через минуту ответил им ссылкой на нужный репозиторий. Не пришлось никуда лезть, распаковывать, искать, запаковывать, отправлять почтой или закачивать в облако.
    Повторюсь, что на Гитхабе классный поиск по исходникам: если нужно посмотреть, как что-то сделал в старом проекте, но не помнишь в каком — можно довольно быстро найти искомое без возни с архивами.

    Итого.
    Код должен лежать на Гитхабе.
    В том числе старые проекты.
    Используйте организации, чтобы рассортировать проекты, если их много.
    Порядок там, где у каждой вещи есть своё место. Придумайте себе правила порядка заранее и соблюдайте их, чтобы не тратить время на ликвидацию беспорядка.
    Ответ написан
    10 комментариев
  • Под какие разрешения рисовать адаптивный дизайн?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    При рисовании любого дизайна встает техническая задача — уместить элементы сайта в указанную ширину. Уместить в заданную ширину тяжелее, чем растянуть до заданной ширины. Растянуть легко на этапе верстки. Поэтому нужно ориентироваться на минимальную ширину в классе.

    1. Мобильные телефоны — 320px. Ориентируемся на viewport айфона, т.к. он самый маленький. У современных андроидов вьюпорт больше, поэтому их игнорируем (растянется на верстке).

    2. Планшеты — 768px. Опять-таки ориентируемся на айпад в портретной ориентации , т.к. у андроид планшетов вьюпорты обычно имеют размер от 800×1200 или совпадают с айпадом. Планшеты с вьюпортом 600×1024px устарели. К тому же ничего страшного, если в вертикальной ориентации сайт на таком планшете будет выглядеть как на мобильнике, а в горизонтальной ориентации — как на десктопе.

    3. Десктоп и планшеты в ландшафтной ориентации — 1000px. Почему 1000, а не 1024: первое, в настольных браузерах полоса прокрутки съедает (обычно) 18px ширины; второе, от 1000px верстальщику удобнее расчитывать размеры в процентах, а до 1024 все равно растянется при верстке.

    В принципе, этого достаточно, чтобы верстальщик справился.

    Если дизайн не имеет максимальной ширины и тянется от края до края окна браузера, то на усмотрение дизайнера можно нарисовать еще один или несколько эскизов для более широких экранов.

    В каком порядке рисовать? Смотря как поставлено тех.задание. Чаще всего в задании описан полный функционал для настольной версии. Тогда проще нарисовать дизайн под 1000px и перекомпоновать под 768 и 320, выбросив или упростив по пути менее значимые элементы сайта. Т.е. двигаться от сложного к простому.

    Верстать при этом удобнее от меньшего экрана к большему (от простого к сложному). При mobile first верстальщику приходится дописывать новые стили для бóльших экранов поверх базовой версии в 320px вместо того, чтобы обнулять написанные для настольных браузеров стили. В результате для мобильника css весит меньше и парсится быстрее.
    Ответ написан
    Комментировать
  • Где посмотреть примеры качественного кода вёрстки сайтов, лендингов, веб-приложений?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    Первый путь.
    На Гитхабе поискать по ключевым словам (BEM, SMACSS, OOPCSS) — найдутся бойлерплейты и стартеркиты, которые по определению должны быть хорошего качества.

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

    Второй путь.
    Искать в Гугле людей, которые пишут про BEM, SMACSS, OOPCSS и прочих крутых фронтендеров. Искать их профили на гитхабе, изучать их проекты. Если они пишут про методологии, то они явно их используют в работе.
    Ответ написан
    Комментировать
  • Где найти того, кто "оценит" твой код?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    Для начала максимально упростите жизнь ревьюверам. Чем меньше усилий потребуется с их стороны, тем больше шанс получить код ревью. Отправлять на почте zip-архив и просить посмотреть — это для ревьювера неудобно, многие откажутся. К тому же как передать комментарии обратно.

    Для каких-то маленьких простых вещей делайте демку на codepen.io или аналогичных сервисах — это очень удобно и быстро открыть ссылку, увидеть код и результат, форкнуть, исправить или оставить комменты.

    Если это уже сайт (даже одностраничник), заливайте его на github pages (https://pages.github.com/).
    Для этого вам придется разобраться с git (если еще не изучили), но git вам точно в профессии понадобится. Когда код на github, его удобно просматривать и оставлять комментарии к конкретным строкам кода, или сделать исправления через pull request. К тому же, не покупая домен и хостинг, вы соберете себе на github портфолио.

    Когда вам будет что показать, ищите ревьюверов прямо здесь на тостере.

    Дополнил этот ответ и написал статью на paulradzkov.com/2016/code_review
    Ответ написан
    Комментировать
  • Почему не совпадает верстка с реальными устройствами?

    paulradzkov
    @paulradzkov
    Дизайнер, верстальщик, начальник отдела UI
    Вы неправильно настроили панель разработчика. У мобильных телефонов количество физических пикселей больше, чем количество «css-пикселей» в браузере. Разница выражается параметром Device Pixel Ratio (DPR) — это коэффициент умножения, сколько физических пикселей в одном «css-пикселе».

    take.ms/v1Ms8

    В режиме Responsive у Хрома по-умолчанию DPR=1.0 (у макбука по-умолчанию 2.0, т.к. retina-экран). Вы выставили ширину вьюпорта 540px, но у вашего телефона, скорее всего, DPR = 1.5 и разрешение в браузере соответствует 360px (540 / 1.5 = 360).

    Вам надо включить отображение DPR и доработать верстку на малых экранах от 540 до 320px.
    Ответ написан
    7 комментариев