• Какие книги посоветуете начинающему web-дизайнеру?

    mixail_fet
    @mixail_fet
    Дизайнер веб-интерфейсов
    Добрый день!
    Нет, образование не нужно, тем более Вам никто не даст настоящего образование веб-дизайнера. В этом случае, я бы предпочел саморазвитие.

    Что конкретно нужно делать:
    30% теории, мой список книг:

    Якоб Нильсон «Веб Дизайн»
    Стив Круг «Не заставляйте меня думать»
    Майк Монтейро «Дизайн — это работа»
    Дональд Норман «Дизайн привычных вещей»
    Виктор Папанек «Дизайн для реального мира»
    Генрих Альтшуллер «Найти идею»
    37Signals «Getting Real»
    Джеф Раскин - Новые направления в проектировании компьютерных систем
    Джеф Раскин - Об интерфейсе
    Брюс Тогнаццини «Главные принципы интерактивного дизайна»
    Ян Чихольд «Новая типографика»
    Эмиль Рудер «Типографика»
    Нора Галь «Слово живое и мертвое»
    Саша Карепина «Искусство делового письма»
    Мюллер-Брокман «Модульные сетки в графическом дизайне»

    60% практики:
    Рисуйте все что попадется под руку, перерисовывайте шаблоны - это очень помогает, делайте личные проекты, которые только пришли Вам в голову, в конце-концов, берите заказы.

    10% вдохновения:
    Каждый день, перед началом любых работ, заглядывайте на:
    Behance.net
    dribbble.com
    themeforest.com
    Ответ написан
    3 комментария
  • Что такое Redux простыми словами?

    @KnightForce
    Чтобы понять как работает Redux тебе нужно норм вкуривать React.
    Хотя бы для того, чтобы не пугаться props.

    Есть у тебя React. Это все просто JS объекты.
    <Component /> - так позволяет писать движок jsx, который и React его использует.
    Так как структура компонентная, ты должен думать как обновить компоненты в в другой части страницы.

    Принцип такой: компонент обычно обновляется при получении новых свойств - props или когда меняется его объект состояния - state.

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

    Что делает Redux:
    Он не призывает отказываться от state.

    Но есть общий контейнер данных. И когда данные меняются - меняются и компоненты, которые отображают именно эти данные.

    Когда нужно что-то поменять - вызываешь dispatch - специальная функция reducer реагирует на это - и меняет данные как тебе нужно. Когда данные заменятся - компонент Propvider - вызывает рендер у своего дочернего компонента (тот что оборачивает Provider).
    Например:
    <Provider>
       <MyComponent />//Вот сюда Provider пробросит (запишет) новые props.
    </Provider>


    Записывает он это самое глобальное хранилище и все компоненты, для которых поменялись данные - перерисуются.

    mapStateToProps - указывает какую часть этого глобального хранилища будет предоставлять provider.
    Если у тебя оно такое:
    {
       chunkStore: {},
       some: {}
    }

    То если mapStateToProps вернет{store: store.chunkStore}то Provider в props своего потомка пробросит такое: store: store.chunkStore. И ты будешь обращаться внутри к store, но там будет только часть chunkStore (не весь объект, а его поле).

    mapDispatchToProps - т.к. subscribe нет, то это возвращает функции, которые могут внутри себя вызывать dispatch().

    action - описывает то что и на что ты хочешь поменять. Какое поле и какие данные туда поместить.
    Ответ написан
    Комментировать
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Во первых: совершенству нет предела.
    Во вторых: невозможно объять необъятное и впихнуть невпихуемое.
    В третьих: как ты не крутись, а технологии развиваются быстрее, поэтому отставание неминуемо, как следствие приходится всегда чем-то жертвовать ради чего-то более важного.

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

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

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

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

    Меня на программирование пропёрло весьма рано, лет в 14-15. Я ощущал собственное безграничное могущество, послушная железяка выполняла любое моё повеление, любой мой каприз, при условии, что он правильно сформулирован. Если железка не делала что нужно, или делала что не нужно, то это всегда была моя вина, это значило что я прокосячился. Подобное осознание настигло меня весьма скоропалительно, после чего мозг начал усиленно дисциплинироваться, и количество лютых фейлов пошло на убыль.

    Коммерческая разработка - это, примерно, от 70% времени/сил на дебаг и фиксы, потому что мало где процессы поставлены грамотно. По хорошему до сего дня (а мне под 40) я только одну команду видел, где процессы прям вообще очень хорошо поставлены и мне посчастливилось какое-то время с ними поработать. За эти несколько месяцев я подрос на целую голову. Самостоятельно достичь сходных результатов было бы весьма затруднительно.

    Сам я сменил стек совсем недавно, начал в конце 15 года, и процесс продолжается до сих пор. Сменил я по одной простой причине - во всех моих прежних проектах большая часть логики с бэка уехала на фронт, и прекраснейший jQuery перестал справляться чуть более чем полностью. Он, по прежнему, хорош, но задачи, которые приходится решать, требуют совершенно других подходов. Для себя я выбрал React, но в целом на рынке имеются альтернативы. По моим данным очень большим спросом пользуется Angular 2+.

    Когда говорят о фронтенд разработке, постоянно говорят о технологиях, стеке, но почти никто не упоминает, что не стеком единым... Существенная часть разработки - это, для начала, понять задачу и построить у себя в голове модель. Заказчики бывают разные, от очень толковых, до очень безтолковых. Соотношение первых ко вторым примерно 1% и всё остальное... Т.е. в большинстве случаев тебе скажут минимум, своеобразно, плюс ты это поймёшь по своему. Потом, по ходу пьесы, в самые неподходящие моменты, начнут всплывать подробности, которые: забыли упомянуть; ну это же очевидно, ты же профи; мы сами не знали, это только выяснилось; ну это же мелочи, мы думаем тебе это будет не сложно; а ты не спрашивал; и т.п....

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

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

    Если ты попадешь в команду, где люди будут понимающие, квалифицированные, процессы выстроены, а джуну задачи будут сгружать джунские, то, считай, тебе крупно повезло. Шансов на это примерно 1%. Особенно учитывая, что джуны это обычно студенты лет в районе 20...

    Когда я менял стек, то я тоже был какое-то время 35-летним джуном. С этим ничего не поделать, потому что, внезапно, стек это не просто так, и имеется масса нюансов, которые с наскоку не освоишь. Чтобы все пощупать, попробовать на зубок, понять и осознать требуется время и усилия, иногда много времени и много усилий. Да, весь прежний багаж служит опорой и поддержкой, и там, где настоящий джун будет копаться недели, ты за пару часов по аналогии поймаешь идею и двинешь дальше. Но эти пару часов никто не отменял, а идей которые нужно отловить сотни, если не тысячи...

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

    Даже если тебе попадается практически идеальный проект, внезапно оказывается, что твоя оперативная память это 5-7+-2 объекта, а удерживать в голове одновременно нужно сотни...

    Зачем я все это рассказываю? Затем, что это реальность, которая для джунов не делает исключений.

    Термин "фигак-фигак и в продакшен" встречается повсеместно, т.к. ресурсы (деньги, время, кадры) практически всегда весьма жестко ограничены и ничего ты с этим не поделаешь.

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

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

    Теперь относительно того что делать - если в бэкграунде нет сильных скиллов по алгоритмике и структурам данных (олимпиады по программированию, универский курс информатики), то прям очень сильно рекомендую прокачать. Будучи наставником на нескольких курсах фронтенда я постоянно встречают студентов, которые "вроде бы" знают язык, но затрудняются скомпоновать пару циклов с условиями, вот буквально просто виснут на неопределенное время, причем без результата. Лично я рекомендую кодварс. Своих студентов я прокачиваю именно там. Достаточно прорешать 30-40 задачек, чтобы базовые скиллы ушли на уровень рефлексов и перестали парить мозг. Правда желательно решать это все с наставником.

    Косвенный бонус тут будет в том, что ты привыкнешь решать задачи на JavaScript. Я когда менял стек, поначалу мыслил на PHP, и подобный финт на кодварс позволил мне переформатировать мышление на JS. Вот мой профиль на кодварс как пруф: https://www.codewars.com/users/iCoderXXI

    Далее, когда ты освоишься в JS практически, очень неплохо будет досконально разобраться в том как работают замыкания и прототипное наследование. Это прям основа основ, и это спрашивают на каждом первом собесе.

    Понять надо настолько глубоко, чтобы легко и просто, с юморком, рассказывать это любой первой встречной бабушке, да так, чтобы та всё поняла... Это вот прям залог успеха в JS, потому что все остальное держится на этих двух китах. В ютубе имеется курс Зоракса (Zorax) и JavaScript Weird Parts, оба про то же самое, первый на русском, второй на инглише. Кантор, безусловно, крут, но эти двое объясняют попроще и понятнее (имхо).

    После этого прокачиваемся в использовании встроенных методов JS, таких как map, reduce, includes, replace и пр. (на том же кодварс)

    После этого нужно прокачаться в ES6+, стрелочные функции, let/const, деструктурирование, рест оператор, классы, промисы, генераторы, async/await, декораторы - без этих продвинутых штук в современных фреймворках ловить нечего.

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

    Потом уже заостряемся на API форм, DOM, AJAX (fetch/axios), вебсокетах, Localstorage и пр.

    И вот только теперь можно переключаться на фреймворки. Проще всего освоить Vue (по слухам), наибольшим спросом пользуются React и Angular, для общего развития так же неплохо бы немного послушать про Ember.JS.

    React только на первый взгляд выглядит простым, на самом деле это только view-библиотека, а в любом нормальном SPA есть много чего еще кроме view, поэтому React всегда идет в компании Redux, Router, и еще целой толпы всего, что тоже придется осваивать, не только с точки зрения API, но и с точки зрения философии (а нахрена оно вообще сдалось?)

    Перед походами на собесы очень желательно иметь портфолио из нескольких готовых проектов, вылизанных стилистически.

    Далее освежаем базу по JS - типы, замыкания, прототипы, и смело топаем по собесам, будучи морально готовыми завалить первые десять.

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

    Еще вроде большие компании вроде Яндекса устраивают летнее обучение, с последующим трудоустройством лучших кандидатов, но это не точно.

    Оптимистичный прогноз - 6-12 месяцев плотного фигачинга и ты в тренде.
    Ответ написан
    7 комментариев
  • Верстка с нуля: какие основные этапы работы?

    Vlad_IT
    @Vlad_IT Куратор тега Вёрстка
    Front-end разработчик
    Использую vscode+webpack+pug+scss+бэм. Из физических инструментов, основной моник: lg ultrawide 29um69g, рядом прикручен моник от ноутбука повешенный вертикально, подключенный через универсальный скаллер.

    0) Запускаю Spotify :-)

    1) Произвожу установку всех необходимых модулей для сборки. В моем случае у меня набор конфигураций для webpack (отдельные файлы для pug, scss, static и.т.д., выбираю что нужно).

    2) Запускаю avocode, загружаю в него макет. Определяю в нем переменные (в то же время записываю их, чтобы сразу кинуть в scss файл) для цветов, размеров шрифтов и.т.д. чтобы при получении кусочков кода из него, он сразу расставлял переменные.

    3) Запускаю VS Code, открываю нужную папку.

    4) Пишу размету на Pug. Пишу с БЭМ, если встречаю повторяющийся блок, то открываю файл _mixins.pug, в который пишу миксины для повторяющихся блоков, например товаров, пунктов меню, каких-то блоков и.т.д. Pug умеет делать циклы, это ускоряет сильно.

    5) Когда HTML готов, начинаю делать каркас. Если дизайн сделан по сетке, определяю контейнеры, колонки, строки в свои классы (не пишу в html тучи классов аля col-md-6, а пишу в SCSS инклуды в нужные мне блоки, типа @include make-col(2) и.т.д.).

    6) Экспортирую картинки из Avocode. Очень делается просто, указываю папку и просто кликаю экспорт и ввожу название файла и расширения. Преимущественно для иконок использую svg, если нет svg, то ищу эту иконку в интернете (дизайнеры редко рисуют иконки сами, но зато любят вставлять их не в векторе). Если иконка простая, могу сам ее в inkscape обвести, ну и если нет, то экспортирую png в размере (благо авокод это позволяет, если конечно дизайнер не вставил в исходном маленьком размере). Когда есть контакт с дизайнером, трясу его, ибо растр это плохо для иконок.

    7) Пишу стили блоков из страницы. На этом этапе можно на втором монике параллельно смотреть футураму или
    Арчера :-) Но чаще на широком монике слева браузер, справа VS Code, а на втором монике Avocode (может меняться местами с браузером). Мысленно нарезаю страницу на блоки. Для каждого блока (БЭМ) создаю отдельный scss файл (кто-то даже для элемента создает, но мне лень), из него сразу выписываю все селекторы. Иногда могу сначала выписать все селекторы со страницы (но так лучше не делать, т.к. во время работы может потребоваться изменить что-то в разметке), но чаще для одного блока выполняю этот пункт и за ним сразу выполняю пункт 8, потом для нового блока опять 7 и 8 и.т.д.

    8) Пишу css код вместе с Avocode, у него беру нужные мне параметры (а он уже подставил в них переменные), и вставляю в мой код. И параллельно сверяю со скрином макета используя вот это расширение https://chrome.google.com/webstore/detail/perfectp...

    9) Пишу адаптив. Я не могу привыкнуть к методологии mobile-first, поэтому пишу всегда сначала полную версию сайта. Я понимаю, что это чревато всякими проблемами и это типа не модно, но мне норм.

    10) Медиа-запросы пишу прямо в блоках, для каждого блока/элемента/модификатора может быть отдельный медиа-запрос. Но для начала определяю breakpoint'ы для разных экранов (чтобы их не было сотни разных), если использую Bootstrap, то беру его breakpoint'ы.

    11) Добавляю анимашки. Даже если заказчик не просил отдельно (и если не указал отдельно, что нельзя), он все равно будет доволен, а с animate.css+onscreen.js это вообще работа 10 минут. Сложные анимации обговариваю отдельно, чтобы не сделать ненужную работу.

    11) Все снова сверяю, пишу скрипты где надо. Для слайдеров в 99% случаев подходит slick (с доработками конечно, но там хорошее API), для других случаев могу написать свой.

    12) Сдаю заказчику и жду ответа сидя на тостере/пикабу.

    Это чисто мой опыт, опыт фрилансера, не знаю, как делают другие и не могу на 100% утверждать что это 100% правильный способ. Я так и не смог заставить свой конфиг webpack правильно вставлять спрайты svg.
    Надеюсь чем-то поможет мой ответ.
    Ответ написан
    7 комментариев
  • Что такое Virtual DOM?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Ну вот есть DOM. Он медленный, и дергать его просто так не стоит. А есть виртуальный DOM, что-то типа прослойки между вашим кодом и реальным DOM. Вы можете дергать виртуальный DOM сколько вам душе угодно, а прослойка эта соберет всю инфу о том как вы чего делали, и попробует оптимизировать взаимодействие с реальным DOM что бы вышло как можно меньше действий.

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

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

    А теперь добавим между всем этим виртуальную апишку, которая запоминает что она там в прошлый раз создала и что надо в этот раз создать. Вы все так же влоб проходите циклом по массиву и просите виртуальный дом построить новую апишку, а виртуальный дом будет стараться переиспользовать то что у него уже есть, ну и все в таком духе. За счет этого получается нефиговый прирост производительности (но есть потери на работу самого виртуального DOM, зато можно фигачить как хочешь).

    Если же прослойку эту сделать со своим интерфейсом, можно получить слой абстракции для работы с UI. Именно это предлагает тот же React. Слой абстракции над UI. Вы можете работать с реактом, но UI будет отрисовываться не через DOM а скажем... это может быть нативный интерфейс мобильной платформы (гуглить native-react). Ну и т.д.
    Ответ написан
    Комментировать
  • Как легко перейти с jQuery на VUE?

    delphinpro
    @delphinpro Куратор тега JavaScript
    frontend developer
    Конкретно здесь проще, и я бы даже сказал, нужно сделать страницу на jquery =))

    ------------------------

    Если же вас интересует как в принципе заменить jquery на vue, то постараюсь ответить.

    1. Как и в случае jquery, ищем подключаем подходящий пакет. Например этот.

    2. Аккордеон реализуется вручную парой строчек

    <div>
      <h2 @click="toggle"></h2>
      <div v-if="stateOpen">
        Скрытое содержимое
      </div>
    </div>

    {
      data() {
        return {
          stateOpen: false,
        }
      },
      methods: {
        toggle(){
          this.stateOpen = !this.stateOpen;
        }
      }
    }

    Анимации раскрытия по вкусу, с помощью обёртки transition

    3. Аналогично предыдущему пункту. 10 минут на реализацию.
    4. Аналогично первому пункту.
    5. Аналогично первому пункту.
    6. Блин, ну тут то же самое =)) Мне нравится этот пакет: vue-form

    Вот и всё. jQuery можно не подключать.
    Ответ написан
    2 комментария
  • Дизайнер интерфейсов с нуля. С чего начать и как двигаться?

    ZaykaPupkin
    @ZaykaPupkin
    Кратко о себе
    Я бы дал более практичные советы:
    1. Ютуб-> ui process 4-5 видосов.
    2. Ютуб-> ui tutorial 4-5 видосов.
    3. Ютуб-> дизайн интервейсов семинары, лекции часов 6-15 позырить разного в общем.
    --
    4 Гугл -> best ui design 4-5 сайтов скачивайте примеры в папку ui вдохновение
    5 Pinterest - ui design - часа 2-3 пролазить по квадратикам снизу, скачивай примеры
    6 Behance, dribble - каждый день смотри, скачивай.
    -- Прошло 3 месяца, каша голове перемешалась, устаканилась.
    7.1 Типографика, композиция, модульные сетки, вебдизайн - гугл по каждому топику в течении 1-2 дня.
    72 Открываешь фотошоп/скетч/иллюстратор/пэйнт в нем открываешь 3-5 экранов с любого проекта скачанных. И БЫЛА НЕ БЫЛА! ноль ноль перерисовываешь. организуешь слои, представляешь что все это передаешь заказчику, его требования итд.
    8 Идешь на сайт типа dayly ui challenge, или russiandesigncup и пиздрячишь нечто оттуда.
    -- Прошло 3 месяца
    9 Гугл, Ютуб: UX, information architecture, personas, userflow итд. - подтягиваешь UX
    10 Гугл, Ютуб: Resolutions for UI, android screen Sizes/ iOS screen sizes. - сходить с ума в данном пункте - норма. https://stackoverflow.com/questions/2634898/what-a...
    https://stackoverflow.com/questions/13487124/andro...
    11 Гугл, Ютуб: Style guidelines, deliverables UI, deliverables UX - учишься что давать заказчику

    --
    12 ФИНАЛ ПЬЕСЫ: оформляешь красивое портфолио. На качественную презентацию по началу уходит 3-10 дней. Это норма. Наработай 4-6 презентаций, проектов-проектиков из 4-12 экранов. Выкладывай на беханс

    Самое сложное в миллионный раз искать рефы, мониторить еженедельно новые стили, идеи. ctrl+c ctrl+v, сохранить изображение как... в первый год - самые частые действия.
    книги: куча списков, Отдельные книги по типографике, композиции, интерфейсам итд можно потом, когда возникнут вопросы связанные с ПРАКТИКОЙ. По мне беханс и блоги ux чуваков с живыми кейсами лучше. на skillshare много инфы и на slideshare (в росси не доступен по впн ходи)
    После портфельки и понимания процессов го на фриланс делаешь первые 5-10 проектов по рабским ценам за отзывы. Гордость можно засунуть в жопу. Дальше все зависит от качества портфельки, социальных навыков, умения делать бизнес в сети. Можно продолжить на биржах, можно отправить 100500 писем студиям с предложением о выполнении заказов за 10-30 процентов им. Можно самому стать агенством.
    По деньгам - это не нефть и даже не солярка. 10-30тр по началу. Потом как повезет. потолок среднему фрилансеру за проект 100тр. а сколько ты его будешь делать(неделю или 2 месяца и спать по 5 часов в сутки) никого не епет.
    Ответ написан
    3 комментария
  • Дизайнер интерфейсов с нуля. С чего начать и как двигаться?

    OtshelnikFm
    @OtshelnikFm
    Обо мне расскажет yawncato.com
    Делай свой сайт, учись и пиши. Сложится лояльная аудитория, пойдут первые заказы.

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

    Учи английский и подтягивай его. Будешь общаться на западных площадках. Но я говорю о развитии как фрилансер - т.к. реалии таковы что HR и говорить не будут - они шаблонны и отметают как только видят что возраст от 25-ти и к 30-ти вообще не смотрят джунов. Они же как роботы - мало у каких эйчаров реально мозги работают. Все думают что выпускник в 21 год это золотой теленок.
    Ответ написан
    Комментировать
  • Студия дизайна и ВЕБ разработки - как правильно организовать?

    Во-первых, попахивает рекламой.

    Во-вторых, вы понимаете вообще для чего вы делаете студию?

    Расскажу свой пример и наблюдения.

    Я работаю с человеком уже несколько лет, я - как разработчик, он - как организатор, следовательно и клиенты на нем. Так как клиентура вполне серьезная, студия потребовалась лишь для того, чтобы показать свою "серьезность", потому что каждый клиент говорит: вас конечно рекомендовали, мы заинтересованы, но можно посмотреть работы. Как вы понимаете, кинуть список сайтов это не серьезно. По этой причине организован, прошу заметить, сайт (юридически и физически студии нет), который выполняет две функции: предоставляет портфолио и предоставляет краткую информацию о нас. Больше он ни для чего не используется.

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

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

    То что вы пытаетесь организовать - организовывается просто. Вам нужно искать клиентов и организовать работу между двумя-тремя людьми на удаленке. Очень много "студий" именно так и работают.
    Ответ написан
    Комментировать
  • Студия дизайна и ВЕБ разработки - как правильно организовать?

    Как для дизайн студии, дизайн вашего сайта - 2005 год, т.е колхоз, думаю начать можно с этого.
    Кстати, у вас там fontawesome не загружается.
    Ответ написан
    2 комментария
  • Возможен ли план самообучения WEB разработке?

    dimovich85
    @dimovich85 Куратор тега CSS
    https://u-academy.net/
    Советов надавали, я накидаю ссылок:
    Веб-стандарты Этот канал интересен уже тогда, как основа заложена. Много полезных и интересных докладов.

    Дмитрий Лаврик Много бесплатных материалов, классные платные курсы, для новичков и для среднего уровня.

    HTML Academy Много хороших материалов для изучения

    Илья Кантор Много материала по JS

    Master-CSS Здесь я нашел много бесплатных видео по настройке разных плагинов, в общем, для старта отлично, но когда поймешь JS, то сам сможешь разбираться.

    Шпаргалка по jQ В голове такие вещи обычно не держу, что-то, что часто использую помню наизусть, а так - всегда подсматриваю.

    Learn JavaScript RUS Классный учебник по JS.

    CodePen и JSFiddle В процессе обучения важно на практике применять полученные знания. Каждый раз собирать файлы, шаблоны, подключать либы, настраивать сборщики и тд лениво, очень классно, что можно в браузере сразу все сделать и даже сохранить, расшарить.

    Webmassa SVG Видео по работе с SVG.

    Юра Артюх Классные стримы по созданию анимаций. WebGL, SVG, Canvas, CSS - все тут.

    StackOverflow Авторитетный ресурс по поиску решений.

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

    W3C Specs, W3School - инфа из первых рук.

    Писал ссылки по мере попадания под руку)

    Успехов!
    Ответ написан
    Комментировать
  • Вёрстка email сегодня - табличная или блочная?

    tema_sun
    @tema_sun
    Не потеряла. Верстают таблицами.
    Но для этого есть удобные инструменты типа zurb foundation (https://foundation.zurb.com/emails.html)
    Ответ написан
    Комментировать
  • Какие учебники по практическому применению JS и JQuery можете посоветовать?

    Если можете в английский - Javascript30
    Это был своего рода челенж, где парень в течение 30 дней ежедневно писал какую-нибудь штуку на ванильном JS.

    Попробуйте посмотреть какой-нибудь курс на Udemy. Там частенько делают курсы, где максимум практики. Например тут.

    Пара видео от CodeDojo, где пишется TODO на JS. Сначала в свободной форме, а потом - переписывается под MVC. Неплохо зайдет для понимания того, как написать что-то большее, чем небольшую фичу для придания динамики. (К слову, на канале есть и другие хорошие материалы).

    Надеюсь, листали Фленагана. Там не очень много практики, но переварить еще раз ключевые вещи вроде принципа работы объектов и прототипы будет полезно.

    Еще неплохая практика - разобрать работу какой-нибудь библиотеки, которую часто используете. Никогда не интересовались, как работает под капотом jQuery? Где-то на хабре была даже серия публикаций на эту тему.
    Ответ написан
    1 комментарий
  • Каков сценарий использования git для одного разработчика?

    gobananas
    @gobananas
    finishhim.ru
    Делаете ветку master, ветку dev и отдельные ветки под отдельные фичи.
    Делаете 2 сайта - один сам проект (основной) - на него выкатываете master, второй сайт тестовый - на него выкатываете ветку dev. Остальные ветки разрабатываете, сливаете с dev выкатываете на тест, если там всё нормально то dev сливаете с мастером. За ноут просто когда садитесь если мастер новый есть делаете git pull и стягиваете новую версию
    Ответ написан
    11 комментариев
  • Верстка еще актуальна на фрилансе?

    @kiberlain
    Всё верно "даже смысла нет изучать из-за переполнения рынка". Я полтора года просидел на фрилансе, никому не советую. Работа над хотелками заказчика может растянутся на месяц, заказчик может кинуть (и такое было, да). Есть вероятность найти адекватного менеджера (у которого целая ферма из такой вот дешёвой рабочей скотины), они ещё могут скидывать более менее регулярные заказы, но оплата будет небольшой. В офисах примерно тоже самое (если взять какой-нить город милионник, то 100 веб-студий где верстаки верстают за копейки и 5-10 топовых, где платят нормально но верстаки там сидят ровно и нет никакой текучки), но там хоть шансы получить свои гроши - повыше. Сейчас мне стыдно, что я несколько лет посвятил себя этой работе. Опозорился со своим выбором конкретно. Хотя сейчас верстаю вполне себе на уровне
    Ответ написан
    15 комментариев
  • Как въехать в программирование (ООП, паттерны)?

    GTRxShock
    @GTRxShock
    Full-stack developer (Symfony, Angular)
    если программируете на php 2-3 года, то пора бы перед сном почитать РНР: объекты, шаблоны и методики программирования (Зандстра) желательно в бумажном варианте.

    + Паттерны проектирования (Фримен) для общего/наглядного понимания паттернов
    + www.phptherightway.com основные тезисы
    + Рефакторинг: улучшение проекта существующего кода (Фаулер) & https://refactoring.guru/ru на будущее, к чему стремиться :)
    Ответ написан
    4 комментария
  • Как въехать в программирование (ООП, паттерны)?

    @Wentixon
    Шаблоны проектирования с человеческим лицом
    К сожалению, не успел к началу вопроса, многое уже посоветовали, но эту статейку вроде не успели еще кинуть. Недавно нашел ее и просто поразился как просто и доступно это изложено + с примерами кода на php. Просто шикарный перевод великолепной статьи!

    От себя же хочу сказать, что единственный способ понять паттерны - это столкнуться с проблемами которые они решают, ибо паттерны ни что иное как шаблоны решения каких то проблем (и предотвращения). Так что делаем вывод - нет проблем, не может быть и решений (конечно, вы просто не осознаете, что они есть, так как проект растет довольно медленно и чаще это какие то правки или добавление нового функционала, который не зависит от старого). Я очень долго пытался с ними разобраться, пробовал читать все перечисленные книги, но вроде читаешь такой и типа понимаешь, но с другой стороны какбы и нет. Вроде понятно, но где это применять хрен знает. Вообщем, как уже сказали, нужны реальные проблемы и тогда открываешь книгу с решениями этих проблем и думаешь какое решение выбрать. Это как с рецептами.. Хочешь что то приготовить, можешь как бы и сам, но не факт, что вкусно получится, тогда открываешь книгу проверенных рецептов и начинаешь применять все по шагам, опираясь при том на ингридиенты, которые у тебя имеются.

    Так что посоветую 2 варианта изучения.
    1) Тупо работаешь над сложные проектами, только действительно сложными, а не сайтиками на cms. И со временем ты начинаешь встречаться с проблемами. Тогда открываешь паттерны и тебе не придется даже как то их особо понимать, потому что это будет естевственно для тебя. Я думаю ты используешь ide вместо редактора кода. Но к примеру я помню тот момент, когда я пользовался саблаймом и знал, что есть ide, но я писал на тот момент простые вещи и когда мне говорили, почему я не юзаю ide, ведь в ней столько всего, я не понимал их потому что мне и саблайма за глаза хватало. Но пришло время, когда надо было то и се и саблайма стало мало. И тут открываю ide, а там уже есть все необходимое и думаешь в такие моменты, как я раньше этим не пользовался. А дело в том, что раньше и не надо было. Может неудачный пример, но вы поняли ) Конечно, этот вариант изучения не совсем реален, по скольку сложный проект еще найти надо, да еще попасть в команду, которая не говнокодит, так как и крупные проекты бывают достаточно плохо написаны. Но можно как вариант к примеру делать свою cms и применять в ней как можно больше паттернов.

    2) Тупо садитесь и изучаете паттерны (как и делал я). Но не просто изучаете, а к какждому паттерну придумываете как можно больше проблем, которые может у вас были или могут быть, так как паттерны в большинстве случаях любят описывать в метафорах, но чаще это получается слишком абстрактно, поэтому нужно чтобы вы придумали свои конкретные задачи, где бы вы попробовали применить этот паттерн. И второй этап - садитесь и пишите эти задачи. Тупо открываете свой яп и реализовываете паттерн. При чем несколько раз с разными проблемами.

    Также советую четко понять uml диаграммы. Таким образом, чтобы освежить паттерн вы не будете читать примеры, а просто посмотрите диаграмму и сразу вспомните, зачем он нужен и как его можно реализовать.
    Вот пожалуй и все
    Ответ написан
    1 комментарий
  • К верстальщику: кого считаете профи? "средний час" верстки? Навыки?

    Maksclub
    @Maksclub
    maksfedorov.ru
    Для меня ориентиром являются
    сайты Студии Лебедева,
    CSSSR
    Ответ написан
    Комментировать
  • Стал работать по часам и обнаружил, что выходит 6 часов в день. Это нормально?

    Maksclub
    @Maksclub Куратор тега Карьера в IT
    maksfedorov.ru
    Не забывайте, НИКОГДА не забывайте, что в ваше рабочее время входит не только полезная работа (написание кода):
    - разобраться с той или иной информацией, изучение проблемы
    - анализ и преоктирование
    - просто изучение нового (подходы, библиотеки)
    - отдых в определенном проценте (не считая обеда)

    Если за вас это не делает работодатель, делайте за него.
    В будущем, если будете управлять коллегами — делайте это для них.

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

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Обязательно:
    1. Главная - приветствующая посетителя витрина: новинки/акции/новости
    2. Корзина - просмотреть, изменить кол-во позиции, удалить позицию, оформить заказ.
    3. Контакты (название, реквизиты/ИНН, почта/телефон/другие способы связи, расположение(адрес/карта) точки(-ек) продажи(-ж), время работы)
    4. Процесс покупки - условия продажи, порядок оформления сделки и договор-оферта.
    5. Оплата - возможные варианты оплаты.
    6. Доставка - возможные варианты доставки.
    7. Гарантия на продукцию и условия возврата приобретённого товара.

    Необязательно:
    1. ЛК(рега/логон): покупки, статусы заказа и т.д.
    2. Быстрый поиск наличия по наименованию/идентификатору с выводом цен.
    Вывод результатов - в LIVE-режиме при наборе и без изображений: их выводим по клику на строку или по наведению через ajax - onhover.
    3. Страница акций, условия проведения и список товаров (с ссылками на сам товар), участвующих в акции(-ях).
    4. Партнёрские программы по привлечению клиентов

    UPD: подсказал Александр Прядко :
    Нужно не забыть привести сайт к 152-ФЗ: линк.
    Ответ написан