• Как запустить IE под MacOs?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Пользуюсь следующим:
    1. Виртуальная машина: Parallels Desktop, позволяет работать с окнами IE, как будто они нативные приложения OS X (иконки браузеров появятся в доке)
    2. Для разных версий IE качаю бесплатные образы Windows с предустановленными нужными версиями IE отсюда: https://modern.ie/ru-ru/virtualization-tools#downloads (Выбираете систему, версию IE, Parallells и качаете)
    3. Образы Windows уже готовы к работе, т.е. нужно лишь добавить скачанный образ в Parallels и всё, можно запускать.
    Ответ написан
    Комментировать
  • Как использовать и для чего предназначен main-bower-files?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Он ничего не подключает. Задача этой штуки, собрать пути до всех библиотечек.

    Приведу пример. Возьмем jQuery. Для того что бы использовать jQuery в своем проекте вам надо сделать следующее.
    bower install --save jquery
    bower будет искать пакет с названием jQuery, скачает его и на этом его миссия будет завершена, а у вас в директории bower_components (или как вы ее назвали в bowerrc), будет папка jquery с несколькими файликами. В случае jQuery вам нужен только один файл, он является главным.

    В bower.json пакета jquery указывается главный файл (тот, который собственно и должен использоваться в проекте)
    {
      "name": "jquery",
      "version": "2.1.2-pre",
      "main": "dist/jquery.js",

    вот это вот поле main и содержит имя нужного нам файла. К слову файлов можно указывать сколько угодно и какого угодно типа.

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

    Далее вы можете: сконкатенировать js-ки в один файл, закинуть их в другую тулзу которая постарается найти эту библиотеку в cdn и сделает локальный фэлбэк... вариантов масса. Суть в том что вам не нужно вручную прописывать пути до нужных файлов, это не интересно, скучно, и после обновления пакетов внезапно может поломаться сборка.
    Ответ написан
  • Что должно быть в портфолио веб-разработчика?

    У нас в Icons8 вся команда удаленная, в разных городах, и мы не встречаемся в оффлайне. Вот что нам показывают ребята и на что мы обращаем внимание:

    1. Рассказ о себе хорошим русским языком. Это универсальный совет на все случаи жизни: все можно рассказать и объяснить, и если вы не можете договориться с работодателем на этом этапе, то это — красный флажок. Дальше будет хуже.

    2. Скриншоты систем. Важен общий уровень продукта: насколько он интересен технически, насколько профессионально выполнен дизайн? Этот шаг можно пропустить, если интерфейс плохой: это будет лучше, чем страшные скриншоты с объяснением "дизайнера нам не выделили, делали сами как умели".

    3. Ссылка на гихаб - вероятно, вам будет интереснее работать с заказчиком, который знает, что такое гит :) И наоборот, вот такое лучше не показывать:

    qA071rqN1NTO562bByx5DoJUPVLEBR.png

    4. Вопросы к работодателю. Лучше, если они будут открытыми (предполагающими развернуты ответ) и по теме программирования (а не "кто оплачивает комиссию 12 рублей за перевод зарплаты" — это мелочи).

    Лучший вопрос, который мне доводилось услышать: "как у вас построена работа".

    ПС: Вот пример нашей вакансии brainstorage.me/jobs/8613 и вот — отличный ответ:

    440a14453f4047d4b92eaeb618d90caf.png
    Ответ написан
    2 комментария
  • Как поменять домен Wordpress в файлах?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Можно в wp-config.php вручную прописать. Я вообще эти опции из базы никогда не использую. Во-первых - мешает синхронизации между локалкой, тестовым сервером и живым. Во-вторых это лишние запросы в бд.

    Оптимальный код (первые строчки - ответ на ваш вопрос, остальное - бонус):

    /**
     * Give WordPress it's own directory.
     */
    define( 'WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/core' );
    define( 'WP_HOME',    'http://' . $_SERVER['SERVER_NAME'] );
    
    /**
     * Link our custom wp-content directory.
     */
    define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/content' );
    define( 'WP_CONTENT_URL', 'http://' . $_SERVER['SERVER_NAME'] . '/content' );


    В этом случае корневая директория у вас выглядит так:
    /core/ - оригинальная папка wordpress из архива, скачанного с wordpress.org (имя любое)
    /content/ - копия папки wp-content (плагины, темы, загрузки)
    index.php
    wp-config.php
    .htaccess

    Также не забудьте в оригинальной папке /wp-content/ грохнуть все плагины и темы, папки должны присутствовать, но быть пустыми (только index.php, который там валяется)
    Ответ написан
    Комментировать
  • Как на Западе устроена фронт-энд разработка?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Если подходить к делу правильно, то процесс следующий:
    1. Брейнсторминг на бумаге, продумывание интерфейса и структуры и отображение в 3х вариантах (desktop, tablet, mobile)
    2. Разработка модульных сеток (они же wireframes) - Photoshop, Illustrator, Fireworks или сцеп. приложения для сеток и утверждение их клиентом. В 3х вариантах (desktop, tablet, mobile)
    3. Верстка голого прототипа по этим 3м вариантам (responsive уже давно стандарт де-факто, а не "бонус").
    4. Дизайнер рисует дизайн, четко по утвержденным сеткам.
    5. Правки по дизайну, утверждение клиентом.
    6. Верстка дизайна, тестирование и отладка, утверждение.

    При таком подходе процессы параллельны. Когда есть утвержденная сетка, мы можем работать сразу в 3х направлениях - дизайнер спокойно себе рисует дизайн, в это время верстальщик (он же coder, он же front-end developer) создает голый скелет (прототип) и верстает в него голый контент, а программер (back-end developer) уже может выводить свою часть (динамический контент) в html. Когде же утвержден дизайн, верстальщик этот низкоуровневый скелет начинает "украшать" - добавляются конечные стили (отступы, типографика, цвета и прочее).

    Следует еще упомянуть обязательный "шаг 0". Для корректной работы начиная с шага 1 необходимо получить от клиента реальный контент. В процессе шага 1 этот контент вместе с клиентом доводится до ума, финализируется и утверждается. В современной разработке работать с Lorem Ipsum - дурной тон и путь в никуда.

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

    Из этого всего выплывает:
    1. Дизайнер - это дизайнер. Его стихия - графический редактор. Понимание принципов верстки и веб-технологий вообще - обязательно. Умение самому заколбасить что-нибудь на jQuery не обязательно.
    2. Верстальщик / кодер / front-end developer - это человек, работающий с клиентской стороной (HTML+CSS+Javascript), переносит картинку от дизайнера в код и прикручивает то, что ему дает программер.
    3. Программист / back-end developer / просто web developer - человек, работающий с серверной частью (например, PHP), CMS и т.д.
    Это "минимальная конфигурация" Для более сложных проектов работа делится на более узкие направления и появляются профильные люди.
    Ответ написан
    Комментировать
  • Как начинающие веб-студии и фрилансеры находят заказы на разработку сайтов под ключ?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Пока нет рекоммендаций, портфолио и "связей" - фрилансерские сайты, FFF (friends, fools, family). Особо бойкие и амбициозные могут заняться прямыми продажами, ходите в места скопления ваших потенциальных "клиентов", знакомьтесь, оставляйте визитки и презентации. Создайте что-то полезное (инструмент, сервис) для какой-то локальной ниши и предложите это решение - если оно реально полезно, то у вас начнут покупать, а дальше пойдет кастомизация, поддержка, отдельные решения, рекоммендации и так далее.

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

    И да, ни в коем случае, ни при каких обстоятельствах не начинайте на начальном этапе вкладывать деньги в офис, мебель, технику и прочее. Trello+Git+почта (или другой, более сложный workflow - на усмотрение), сидите себе по домам, в кафешке с ноутами, на крайняк в коворкинге и работайте, работайте, работайте.
    Ответ написан
    4 комментария
  • Как организовать процесс разработки сайтов на Wordpress?

    HeadOnFire
    @HeadOnFire
    PHP, Laravel & WordPress Evangelist
    Знакомая ситуация, до боли знакомая.
    Я бы в этом случае не городил сложным схем - больше шансов запутаться и усложнить (замедлить) процесс, а скорость тут у нас и так не самая сильная сторона. Особенно если клиентский проект на shared-хостинге и git-ом даже не пахнет. Справляюсь так же, как и @i_dozi , "для себя" использую приватные репо на bitbucket.org.
    Относительно мегасрочных мелких фиксов "по-живому" - стараюсь собирать небольшую пачку и делать оптом, но иногда все же приходится делать срочный одиночный фикс, прямо на живом сервере (бывало делал такие правки с планшета, сидя в маршрутке), после этого всегда копирую на локалку и обновляю везде, в том числе репо. Делаю это как можно раньше, чтобы не потерялось. Если вдруг возникает ситуация, когда сижу и не могу вспомнить, где более свежая версия (такое случалось), или долго в проект не лазил, а за это время клиент сам мог что-то поменять - diff в помощь.
    Ответ написан
    Комментировать
  • Как выжить верстальщику на фрилансе?

    iiil
    @iiil
    Инженер и вэб-дизайнер, рисую.
    То, о чем Вы говорите - есть риск фрилансера. У всех есть риски: у тех, кто на постоянке он состоит в том, что они могут упереться, не развиваться, несмотря на все свои знания и скорость работы получать одну и ту же зп. Фрилансер несет риск, который состоит в том, что он может остаться без работы, и оставаться без работы надолго.
    Так что не понимаю к чему такой вопрос задан, как говорится - стоит подумать о постоянке (и к сожалению, возможно не только в сфере it). Все же мы живем в реальном мире.
    Возможно получится работать и параллельно развиваться.
    Ответ написан
    Комментировать