• Старт в WordPress?

    ksider
    @ksider
    Я сварщик не настоящий
    к вышесказанному добавлю еще пару шпаргалок:
    Небольшой мануал для старта
    Иерархия шаблона
    Теги
    Шпаргалка

    добавлю еще сервис для следующего уровня
    Ответ написан
    6 комментариев
  • Какую использовать программу для просмотра иконочных шрифтов?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Для неустановленных попробуйте NexusFont, MainType, Suitcase Fusion. Они же работают и с установленными.
    Ответ написан
    2 комментария
  • Имеет ли смысл склеивать для каждой страницы разные js библиотеки?

    aaadddminnn
    @aaadddminnn
    php it ubuntu debian
    Склейте. Один раз клиент закеширует и всё. да и нагрузка меньше
    Ответ написан
    Комментировать
  • Как на CSS стилизовать DIV, содержащий в себе, к примеру, SELECT?

    mrdubz
    @mrdubz
    front end developer
    Добавьте класс блокам содержащим select-ы и пропишите бордеры
    Ответ написан
    8 комментариев
  • Как повысить ежемесячный доход?

    Если шаришь хорошо в веб разработке, рискни 10-20 тысячами, попробуй перепродавать заказы, например бери на odesk заказы на сайты за доллары, а перепродавай в снг за рубли, беря себе 50%.

    Например средний заказ стоит 400$ для вордпресса.
    Платим дизайнеру 5000 рублей, 5000 рублей верстальщику ворпдресса, остальное (более 10000 рублей себе в карман)
    Так можно брать в день 2-3 заказа, но есть риск что заплатишь а заказчик не примет работу
    Ответ написан
    7 комментариев
  • Сколько времени должна занимать верстка этой страницы у опытного верстальщика?

    @serzhei
    Верстка, программирование
    как по мне, нормально сделать, без адаптивности - так часа 4-5
    Ответ написан
    1 комментарий
  • Сколько времени должна занимать верстка этой страницы у опытного верстальщика?

    TimLee
    @TimLee
    Привет из еженедельной рассылки.

    Если это первый свёрстанный сайт, то неделя это нормально. Если уже пятый, то 2 дня т. к. там нет адаптивности. ИМХО
    Ответ написан
    Комментировать
  • Сколько времени должна занимать верстка этой страницы у опытного верстальщика?

    SerzN1
    @SerzN1
    Challenge me!
    опытный верстальщик по 1 попапу выбора города мог бы заметить что там скорее всего ie6+, и открыв код можно убедиться в этом

    так что ответ этот вопрос не 8 часов + адаптивность, а как для мамонтов минимум 3 дня без всякой адаптивности
    + коммуникации , время на проверку и доработки
    + если адаптивность под таких мамонтов то еще немного дольше

    ПС: делать на фреймворках высоконагруженные сайты - это полный мажертон, если только там не море плагинов оптимизаторов для сборки проекта
    Ответ написан
    Комментировать
  • Сколько времени должна занимать верстка этой страницы у опытного верстальщика?

    @tef
    Как одно из первых заданий норм. Не парься. Наловчишься, потом подобное будет занимать пару дней.
    Ответ написан
    Комментировать
  • Почему один и тот же шрифт по разному отображается в разных браузерах?

    потому что шрифт не стандартный и не гугловский, нужно вручную импортировать, конвертировать через белка фонтс тут
    Ответ написан
    1 комментарий
  • Верстаю сайт, получаю от заказчика "недочет" как быть)?

    zooks
    @zooks
    Frontend
    Такое нужно сразу оговаривать. Если видишь макет явно меньше или крупнее чем нужно - возвращаешь на доработку.

    Попробуй сделать грязный хак:
    body {
      zoom: 50%;
    }

    Неплохо бы увидеть пример верстки.
    Ответ написан
    2 комментария
  • Как найти стабильную удалённую работу Web разработчику? Реально ли?

    @ivkol
    реально. Вакансии с brainstorage - галочка "удаленно"
    Ответ написан
    Комментировать
  • Можно ли соваться на Одеск с таким уровнем работы(фронтэнд)?

    mr_T
    @mr_T
    Web-разработчик
    Сам верстаю много, так что попробую дать советы, но это чисто мое мнение, поэтому постарайтесь реагировать на это соответствующе :)

    Сначала по вопросам непосредственно в этом посте:
    1) Заказчик может такое принять, а может и не принять - тут зависит от того, насколько он дотошен, вот и все . В любом случае нужно понимать, что редко бывает так, что заказчик что-то понимает в том, что вы делаете, поэтому его "хотелки" скорее всего будут относится к его субъективному восприятию внешнего вида сайта. Но так же нужно понимать еще и то, что внимание к мелочам дает хороший результат на это восприятие в том числе :)
    2) Лично я делаю так, чтобы в шаблоне просто можно было написать что-то вроде
    <? foreach ($slide in $slides): ?>

    <? endforeach; ?>
    и не париться о том, что произойдет дальше (в разумных пределах, конечно - чаще всего слайды должны быть определенных размеров, но об этом нужно говорить).

    Теперь по вашему коду:
    1) Попробуй использовать sass/less с автопрефиксами, компассами и пр. - очень будет удобно писать стили.
    2) Лично я крайне редко пользуюсь сторонними слайдерами, поскольку они часто используют кучу невнятных классов, дивов, врапперов, иннер-врапперов, аутер-врапперов, контейнеров и т.д., хотя чаще всего достаточно несколько строк в js, задача которых просто давать нужные классы нужным слайдам, и анимации в css - в итоге так даже быстрее, чем настраивать под себя какой-нибудь сторонний jquery слайдер. А если один раз сделать заготовку на будущее, то вообще все за пару минут можно сделать.
    3) Вместо спрайтов во многих случаях лучше использовать шрифтовые иконки (например, с icomoon.io). Например, для значков соц-сетей. Из приятных бонусов - шрифты можно красить в любой цвет и анимировать, а так же они векторные, что позволяет не париться по поводу дисплеев с высокой четкостью. Можно еще svg, но с ними немного сложнее, зато гибко.
    4) Обычно на подобных сайтах лепят фиксированное меню, которое сужается при прокрутке ниже (что, кстати, опять-таки решается css transition'ами и парой строк в js для задания класса типа small).
    5) #link-services feature лучше сделать не section, а article или figure - так будет правильнее семантически. А section'ами лучше сделать #link-services, #link-portfolio и т.п. Почитай на любом ресурсе о семантическом значении html5 тегов, там много интересного можешь найти :)
    6) Я бы как-то выделил элементы формы при фокусе, сделал их поконтрастнее, а то на некоторых экранах текст может сливаться с фоном инпута.
    7) p.section-description лучше сделать без класса вообще, а в css задать общий стиль для всех абзацев, изменяя его в конкретных случаях при необходимости.
    8) Раз уж сайт такой весь из себя анимированный, то что ж вы не сделали анимацию ссылок :) ? Хотя бы на работах в портфолио обязательно нужно это сделать, причем недостаточно просто картинок, нужны как минимум еще заголовки, которые могут, например, всплывать по наведению. Очень красиво получаются в таких моментах анимации transform: scale(...) вместе с opacity.
    9) header и footer не всегда по одному в одном документе, эти элементы могу вкладываться так же и в article или section. Как следствие лучше дать своим body > header и body > footer внятные классы или айдишники, иллюстрирующие их принадлежность ко всей странице, а не к отдельным блокам.
    10) .feature > aside я могу быть не прав, но мне кажется, что это семантически неверно. Aside должен показывать какую-то часть документа, которая помогает ориентироваться в контенте на сайте (например, фильтры, боковое меню). В твоем случае это просто иконка, так что тут лучше обойтись просто div'ом.
    11) По js: у вас какой-то странный блок сверху, где задаются глобальные переменные. Вы там используете jQuery, при этом не помещая код в $(document).ready. Весь код jQuery, связанный с селекторами (как минимум) всегда должен быть внутри ready. Да и какие-то странные конструкции там вроде var buttonAll = $('.works-button')[0], которые потом используются снова как $(buttonAll). Лучше в buttonAll записать строки с селекторами тогда уж, а не использовать jQuery 2 раза для одного и того же. Да и конструкции вроде $('.works-button')[0,1,2,3] довольно опасны. Тут лучше дать каждой кнопке какой-нибудь атрибут типа data-category (или вообще в href писать #category-name), и написать один обработчик для всех этих кнопок, который просто фильтрует работы по значению этого атрибута. Так будет проще в будущем что-то поменять, при этом совершенно не затрагивая код js.

    В общем, как-то так.
    Ответ написан
    4 комментария
  • В двух словах, что такое БЭМ?

    lexxpavlov
    @lexxpavlov
    Программист, преподаватель
    БЭМ - это такая методология вёрстки от Яндекса. Она подразумевает разбиение страниц на отдельные смысловые блоки (комментарий, пост, заголовок, футер, форма, инпут и т.п.). Каждый блок может состоять из других блоков. Основная идея - как можно больше повысить возможность повторного использования уже написанных блоков, для чего используются модификаторы. Плюс, БЭМ подразумевает отказ от каскадных стилей, потому что они препятствуют повторному использованию.
    Например, на странице есть два разных заголовка (например, отдельно в статье, и отдельно во врезке). Как все привыкли делать это? есть код заголовка:
    <h1 class="header">Заголовок</h1>
    И мы ставим эти заголовки в текст статьи и во врезки:
    <article class="article">
        <h1 class="header">Заголовок</h1>
        <p>Текст текст текст</p>
    </article>
    <aside class="incut">
        <h1 class="header">Заголовок</h1>
        <p>Текст текст текст</p>
    </aside>

    Тогда обычно мы используем каскад, чтобы стилизовать заголовок во врезке:
    .header {font-size: 2em; padding-bottom: 1.5em;}
    .incut .header {text-decoration: italic;}

    Всё хорошо, но теперь мы не можем просто перенести эти стили заголовка во врезке в другое место, потому что эти стили привязаны именно ко врезке (классу incut). Плюс, что ещё хуже, если к элементу привязано несколько различных стилей, образующихся подобными каскадными правилами, то перенести такой внешний вид в другое место становится очень трудоёмко. А также, из-за большей специфичности каскадных стилей, их сложнее "перебить" новым стилем.
    БЭМ предлагает отказаться от каскадных стилей и создавать отдельные стили-модификаторы:
    <article class="b-article">
        <h1 class="b-article__header">Заголовок</h1>
        <p>Текст текст текст</p>
    </article>
    <aside class="b-article b-article__incut">
        <h1 class="b-article__header b-article__header_incut">Заголовок</h1>
        <p>Текст текст текст</p>
    </aside>


    .b-article__header {font-size: 2em; padding-bottom: 1.5em;}
    .b-article__header_incut {text-decoration: italic;}


    Чем больше проект, тем выгоднее использование подобной методологии. На маленьких и средних проектах БЭМ может быть избыточен. Хотя вот была статья habrahabr.ru/company/yandex/blog/234905 про использование в маленьких проектах.

    БЭМ может использоваться самостоятельно, вручную создавая все элементы и блоки. Но существует обширный инструментарий для БЭМа, который помогает создавать библиотеку элементов и блоков.

    Ну вот. Получилось не в двух словах, но менее подробно качественно описать БЭМ не получится, имхо.
    Ответ написан
    Комментировать
  • Какие есть инструменты под windows для ускорения веб разработки?

    iusfof
    @iusfof
    Front-end developer
    sublime text 3 с плагинами

    firefox с firebug

    grunt
    с плагинами
    grunt-concurrent - позволяет параллельно запускать плагины, которые работают так сказать непрервыно. в моем случае это grunt-contrib-connect, grunt-contrib-watch и grunt-contrib-compass
    grunt-contrib-connect - локально создает сервер в связске с grunt-contrib-watch позволяет организовать livereload страницы
    grunt-contrib-watch - постоянно отслеживает изменения в определенных файлах и при регистрации изменения перезагружет страницу загруженную в grunt-contrib-connect
    grunt-contrib-compass - sass/scss в css, имеет свой встроенный livereload
    grunt-contrib-jshint - проверяет на ошибки .js файлы
    grunt-contrib-imagemin - сжимает изображения
    grunt-contrib-copy - копирует файлы/папки
    grunt-autoprefixer - расставляет префиксы в css
    grunt-contrib-concat - конкатеринует файлы
    grunt-uncss - удаляет неиспользуемые стили из css
    grunt-combine-media-queries - группирует медиа запросы
    grunt-contrib-cssmin - минифицирует и конкатеринует .css
    grunt-contrib-uglify - минифицирует и конкатеринует .js

    сохраняю на Яндекс Диске
    для чего?
    Ответ написан
    6 комментариев
  • Какие видеокурсы по изучению английского языка посоветуете?

    @Profatilova
    Самое лучшее -
    rutracker.org/forum/viewtopic.php?t=563735
    rutracker.org/forum/viewtopic.php?t=563824
    rutracker.org/forum/viewtopic.php?t=587008

    Там курс "English for you" 3 уровня. От Beginer до Intermediate. Уроки на английском, но все понято. Объясняют все отлично. Будете реально понимать что как и почему.

    А для того чтобы подтянуть именно разговорный язык, который будет необходим в повседневной жизни нужно читать и слушать журнальчик Hot English Magazine :

    rutracker.org/forum/viewtopic.php?t=1556121
    rutracker.org/forum/viewtopic.php?t=2590059
    rutracker.org/forum/viewtopic.php?t=3061180

    Update
    Еще канал на youtube (для "продолжающих")))
    https://www.youtube.com/user/JamesESL/videos
    Ответ написан
    1 комментарий
  • Как узнать уровень фронтенд разработчика?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    @tnorman уровень логики не ниже, чем на серверной стороне?)) Посмешили.
    Фронт-енд разработчик должен разбираться во фронт-енде, а не в PHP — фтопку PHP, вообще никакого PHP.

    Основы построения баз — да, поскольку появится возможность работы с базами напрямую. Понимать принципы общения с сервером и другими компьютерами, знать про HTTP-заголовки, политику безопасности и, в частности, политику происхождения документа. То есть знание XMLHttpRequest, CORS и (хотя бы) представление о WebSocket, WebRTC.

    Разбираться в клиентских технологиях — HTML, CSS, Javascript, SVG, canvas, многочисленные API, описанные в HTML. И если не знать про WebGL и API, то разбираться зачем это и к чему. Построение DOM, CSSOM, понимание узких мест и тенденций. Основные семантические конструкции и микроданные.

    Понимать box model, visual formatting model, stacking context, работу с формами и элементами, медиа-элементами. Знать, что такое кодировка и как жить с разными кодировками при необходимости, хотя это уже редкость.

    ООП соглашусь — наследование, инкапсуляция, понимание роли прототипов и умение их использовать. Знание основных паттернов и парадигм. Добавлю модель событий — просто знание (не жалкие 5 штук, а реальный охват, включая MutationObserver). Ну и регулярные выражения.

    AJAX? Если не брать в расчёт XML-RPC, SOAP, WSDL, то выделять это в отдельный вопрос не стоит. А вот event loop (включая tasks и microtasks), на который завязана модель событий и все асинхронные вызовы знать обязательно. Также быть в курсе, что такое promise, зачем они и как использовать.

    Знать основы проектирования, UX и построения UI. Очень много в работе фронт-енда основано на взаимодействии человека и интерфейса. Непонимание основ UX приводит к неприятным последствиям.

    Что же насчёт Backbone или других конкретных технологий — это вообще дело наживное и акцентировать внимание не стоит. Опыт приветствуется, но не является обязательным. ну только если проект не горит.
    Безусловно, знание технологий разработки нужно, но я бы тогда поставил на Node.js, Grunt/Gulp, AngularJS.
    Ответ написан
    5 комментариев
  • Что нужно знать помимо javascript для фриланса (в частности на oDesk)?

    zoonman
    @zoonman
    ⋆⋆⋆⋆⋆
    Из своего опыта работы на одеске скажу, что более всего ценится умение решать задачи в поставленный срок и в соответствии с пожеланиями заказчика. Это дает рейтинг и постоянных клиентов.
    При общении точно указывайте количество времени, которое займет работа. Крайне не рекомендую ввязываться в проекты, которые кажутся сомнительными при первом прочтении.
    Рекомендую работать с клиентами из развитых стран (США, Канада, Великобритания, Германия). Вариант с трекером времени самый лучший. Fixed price немного хуже.
    И учите английский.
    Ответ написан
    Комментировать
  • Что нужно знать помимо javascript для фриланса (в частности на oDesk)?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Имеет ли смысл рассчитывать на работу js-специалиста (т.е. в случае если навыки js используются значительно интенсивнее других)?

    Безусловно

    Возможно ли это на фрилансе?

    Безусловно

    Что лучше учить в связке с js?

    Учить CSS, HTML, SVG, фреймворки, и разного рода интерпретаторы (HAML etc.), препроцессоры (SASS, Stylus etc.).

    Имея базовые знания по CSS, HTML стоит ли нацелится на них и периодически использовать js?

    Без этих знаний никуда.
    Пример: анимация в CSS быстрее, используем её. Для старья используем таймеры.
    Пример: для хорошего соответсвия UX используем элементы формы, из состояния, события.

    Или лучшем будет изучение frontend фреймворков? Необходимы ли при этом будет в дальнейшем много верстать? Насколько перспективна эта сфера деятельности?

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

    Если использовать github-аккаунт как часть портфолио, что наиболее привлекательно будет в нем для работодателя?

    Примеры решения конкретных задач. А разве в гит можно выложить что-то неконкретное?))

    Имеет ли смысл довести какие-то свои задумки до конца перед началом поиска работы, или лучше начать сразу а уже стабильно оплачиваемые заказы могут пойти в портфолио?

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

    Возможно ли получить помощь\поддержку в начале пути фрилансера от человека активно этим занимающемся?

    Возможно. Но на условиях подмастерья. Будьте готовы к этому.

    Ну и напоследок чисто-субъективные вопросы на которые я не жду аргументированного ответа, а просто совета, основанного на жизненном опыте:
    Стоит ли нацеливаться на javascript или лучше менять акцент (или вовсе бросать js) на другой язык?

    Ваще непонятный вопрос. Если вы категорически не согласны с концепцией JS — бегите прочь от него. Если всё понятно — зачем спрашивать?

    Стоит ли уповать на фриланс или лучше искать обычную работу?

    Фриланс и есть обычная работа. Вопрос абсолютно не связан с программированием или языком программирования.
    Ответ написан
    2 комментария
  • Java и удаленная работа (фуллтайм) - порог вхождения?

    Kaigorodov
    @Kaigorodov
    Инженер, математик, мечтатель
    Очень хороший вопрос.
    Мой опыт: java -- это в основном enterprize. Поэтому фриланса на нём меньше, часто сидят в офисе.
    Выбор попытать делать удалённо долгосрочно большие проекты на java -- это очень правильно. Я сейчас на такой работе, это кайф. Скорее всего лучше web-проект, а не swing.

    Что надо знать: java core, collections, threads, servlets.
    А вот spring, jsp -- они не на всех проектах и мне лично не очень нравятся. А технологии которые мне не нравятся со временем умирают )))

    Можно пробовать делать проект для заказчика и просить (выпрашивать) тестовое задание, после этого денно и нощно работать. Если кого подведёшь -- это их проблемы, они хотят сэкономить и идут на риски. Не обманывай, не бойся, не тупи, думай, старайся.

    Я вообще не знал java, взял задание, мне скопировали на диск jdk, javadocs. И сделал за 3 дня. Это первая работа.
    Даже если задание затянешь, всё равно доделай. Это уже можно показывать его другим. Также это база, которую можешь улучшать. Если ещё чего интересно, стучись в личку.
    Ответ написан
    3 комментария