Контакты

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

Все теги (110)

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

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

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

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

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

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

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

    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
    Большинство советует потратить полгода-год, работая в компании, но вопрос стоит «Как начать брать крупные заказы на фрилансе?». Да, работа в продуктовой компании поможет поднять свой уровень, но это не тот ответ. После работы в хорошей компании может и не захотеться возвращаться во фриланс. Вопрос стоит «как повысить свою компетентность, продолжая работать на фрилансе, и выбраться из потенциальной ямы лендингов и бложиков?»

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

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

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

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

    Саморазвитие на фрилансе по-любому будет идти медленнее, чем в развитой продуктовой компании.
    Ответ написан
  • Распараллеливание процесса верстки между верстальщиками?

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

    0. Создается общий репозиторий для проекта.
    Все работы ведутся сразу в нем. Чем чаще делаются коммиты, тем раньше вылезут и будут исправлены проблемы. У каждого компонента есть свой css/less/sass файл, чтобы легче управлять кодом и избегать merge-конфликтов.

    1. Основные строительные блоки:
    - Типографика и стили для контента (таблицы, цитаты)
    - Элементы форм + стили валидации
    - Декоративная графика (иконки, плашки)
    - Модульная сетка (сразу респонсив)

    Каждый верстальщик отвечает за свой кусок работы и создает демо-страничку с перечнем компонентов, которые он сверстал. Работа верстальщиков не пересекается.

    2. Повторяющиеся компоненты:
    - Навигация
    - Ленты новостей, событий, блогпостов, результатов поиска, чего угодно
    - Типовые формы (логин, регистрация, поиск)
    - Табы
    - Слайдеры
    - и так далее

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

    После этих двух этапов у команды готов UI-kit проекта.

    3. Предварительная сборка всех шаблонов страниц с реальным контентом

    Работа распределяется постранично. Каждый верстальщик копипастит блоки из UI-кита и наполняет реальным контентом. В конце команда оценивает, где что еще нужно доделать.

    4. Редкие кастомные компоненты и модификации

    На основе проблем, которые вылезли на третьем этапе, каждый верстальщик допиливает блоки, за которые он отвечает.

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

    Обо всем этом говорят Atomic Design, ITCSS и многие другие методологии.
    Ответ написан