• Как сегодня верстают такие бордеры?

    @ksyu_gl
    Учусь верстать
    Ответ написан
    Комментировать
  • Как сегодня верстают такие бордеры?

    profesor08
    @profesor08 Куратор тега CSS
    Псевдоэлементы в помощь:
    Ответ написан
    2 комментария
  • Над чем нужно работать, что улучшать?

    Vlad_IT
    @Vlad_IT
    Front-end разработчик
    1. Закомментированный код на гитхабе - не хорошо. https://github.com/marinarodkin/aviasales-app/blob...
    2. Минимум логики в render функции компонента. Все сложные конструкции переносите в методы, а лучше в отдельные компоненты (тогда сможете легче контролировать перерисовку компонентов через shouldComponentUpdate , чтобы они не перерисовывались, если данные не поменялись). Вы можете прямо как методы писать стрелочные функции:
      class Flight extends Component {
          getWeekDay = (date) => {
              //..
          }
          // ....
      }

    3. Вы в половине случаев используете точку с запятой, а в половине нет. Используйте чаще.
    4. Атрибут for нельзя использовать в jsx (как и class, как вы знаете). Вместо for пишите htmlFor
    5. Смотрите консоль инструментов разработчика, там есть ошибки.
    6. Освойте shouldComponentUpdate, он позволяет контролировать перерисовку компонента при изменении состояния или пропсов. У вас при изменении кол-во пересадок, перерисовывается весь список билетов, даже те, которые уже были в этом списке. Многие скажут, что еще рано такое учить, но я не согласен. Если не учиться контролировать перерисовку еще в начале обучения, то можно написать очень много тормознутого софта.
    7. У вас данные ticket.json подгружаются хардкодно из github, это не хорошо, т.к. этот файлик с данными есть в папке public, и если потенциальный работодатель захочет поменять там что-то, он не увидит изменений (т.к. грузится с гитхаба).
    8. У вас если в данных в параметре departure_date стоит 11.10.2018 (т.к. сегодня), то отобразится это как "11 окт 2018, вс", т.е. день недели неправильный. А он неправильный потому, что это не октябрь, а ноябрь. Ошибка в методе getDateFormat
      const newDate  = new Date (year, month, day, );
      const monthName = ["дек", "янв", "фев", "мар", "апр", "мая", "июня", "июля", "авг", "сент", "окт", "ноя", "дек"];
      const newMonth = monthName[newDate.getMonth()];

      конструктор Date вторым аргументом ожидает номер месяца, нумерация которого начинается с нуля. т.е. 0 - январь, 1 - февраль, 11 - декабрь. Судя по monthName вы подозвевали, что есть что-то неладное, но ошибись с реализацией. monthName должен иметь обычный вид, начинаться с января и заканчиваться декабрем, т.к. нулевой элемент массива как раз подходит по логике с нулевым месяцем. В getDateFormat, а также в getWeekDay, вычтите из month - 1
      const newDate = new Date(year, month - 1, day)
    9. У вас в тех же getDateFormat и getWeekDay в конструкторе Date вы в конце аргументов пишите запятую, так не нужно делать. Это не вредно и не полезно, просто дурной тон. Там в любом случае будет undefined, хоть с запятой хоть без нее.
    10. Картинки тоже грузятся с marinarodkin.github.io, измените.

    11. const getStopsNumber = (stop) =>{
            switch (stop) {
              case 3:
                return "3 пересадки"
              case 2:
                return "2 пересадки"
              case 1:
                return "1 пересадка"
              case 0:
                return "без пересадок"
              default:
                return // это не нужно делать, писать return. Если вы удалите эту (и строку выше), то результат будет такой же - undefined
            }
          }

    12. Если бы в SideBar пропс stopsData был не объектом, а строкой или числом, то компонент SideBar можно было бы безболезненно превратить в PureComponent. Ну это так, к слову об оптимизации.
    13. Я бы в stopsClick передавал не объект события e, из которого вы потом берете id элемента через e.target.id (что не есть гуд), а сделал бы стрелочную функцию (или bind), в которую бы передавал id. Вот так
      <input onClick={() => this.props.stopsClick("allStops")} />
      <input onClick={() => this.props.stopsClick("noStops")} />

      Если это читают опытные ReactJS разработчики, рассудите пожалуйста. Согласен, что на каждый компонент будет создана своя копия функции, но по крайней мере, не нужно взаимодействовать с DOM напрямую.
    14. Это не красиво
      if( this.state.stops.allStops === false && this.state.stops.noStops === true && this.state.stops.oneStop === true && this.state.stops.twoStop === true && this.state.stops.threeStop === true  ){
               newStops = {...this.state.stops, allStops: true}
          }

      мне кажется, на дальнейшую логику это никак не играет роли, лишь создает глюк, когда выбираешь все чекбоксы кроме "все", и если кликнуть после этого на один из них, он не отожмется, а лишь включится чекбокс "все".
    15. Попробуйте везде сократить повторяющиеся конструкции. Например начните с stopsClick Не говорю, что у вас сразу получится, это приходит с опытом. Но просто попытайтесь подумать, как это можно сократить.


    Может я многое высосал из пальца, но это будет вам полезно. Учитесь, развивайтесь. Удачи вам в этом :-)
    Ответ написан
    1 комментарий
  • Чему научиться кроме HTML, CSS, JS для фриланса на upwork?

    @Ravenio
    Доброго времени суток.
    Отвечая на вопрос.
    По количеству заказов, на данный момент, по апворку у заказчиков популярны PHP/Wordpress/Laravel, WP вне конкуренции.
    В сторону JS есть много заказов по React/Angular/Node.JS, меньше по Vue.
    Если же говорить про то, что необходимо, то начиная с самых низов от WP сейчас никуда не деться, просто навыками HTML/CSS на апворке да и вообще уже никого не удивить.
    На JS/React/Node.js заказы выше уровнем, без опыта и хорошего портфолио их брать сложнее чем на том же WP.
    Ну и общее.
    Про идеальный английский - неправда. Знать его конечно необходимо, но уровня intermediate вполне.
    По поводу маленьких ставок и быть первым - тоже, не совсем:
    • Во-первых это не всем известная помойка. Да, заказчики бывают разные, но основаная масса желает платить специалисту, не равняйте менталитет заказчика из США с нашим, у него не укладывается, что специалист ставит 5-8$ за час. В среднем, все начинают в диапазоне 12-15$, хотите можете и с 5$ начинать, но лучше сразу привыкать ценить свой труд. И вас ценить будут в ответ. Пример из опыта заказ на установку WP, и темы без кастомизации и прочего ушел за 35$/час, на вопрос почему, заказчик сказал, потому что я вижу что вы сделаете за час, а человек будет за 7$ ставить мне его неделю, может заказчик и не прав, но такой ход мысли у многих. Повторюсь есть и иные случаи, но потом часто можно в Job feed увидеть - "даю апворку последний шанс, чтобы сделать мою работу, предыдущий фрилансер не справился".

    • Во вторых, там необходимо ответить в течении определенного времени, обычно окно составляет около 10 минут. Ваш cover letter выстраивается у заказчика релевантно вашим скилам, портфолио, последним выполненым работам, но никак не зависит от того вы ответите первая или десятая.

    Ни в коем случае, не при каких обстоятельствах не работайте за отзыв и за очень маленькую ставку, мошенников и сволочей большое количество. Случаев работы за 5$ два месяца - масса. Начиналось все с небольшой правки, и обещаний оставить хороший отзыв, а потом в процессе узнаешь что такое JSS, что такое скрытые отзывы. И так люди работали.
    Старайтесь избегать заказчиков из Пакистана, Индии. Русскоязычных старайтесь тоже избегать, вообщем ищите заказы в странах от Германии и западнее.

    В любом случае, как раз где-то через 6-8 месяцев обучения, вы уже сами будете отвечать на этот вопрос другим. Удачи вам, Марина!
    Ответ написан
    2 комментария
  • Как (и возможно ли) дотянуться до 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 комментариев
  • Как наверстать знания в javascript?

    Yertuwernat
    @Yertuwernat
    Кратко о себе: живу в России, не женат, характер
    Как вариант ты можешь работать без всех этих технологий: babel, webpack, typescript и тд и тд.

    Вообще без них!

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

    Я например создаю веб-приложения "для себя" ну и для всех кому понравится, и пишу код так как мне удобно, и не страдаю вообще, и для работы мне хватает старенького мака 2005 года выпуска.
    В принципе, работая так, можно даже делать на заказ. Но чаще всего заказчики дебилы и хотят чтобы разработчик работал по стандартному шаблону, чтобы его потом можно было бы уволить и нанять другого. Это страх и недоверие типичное в наших людях.

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

    И те кто вынужден работать в этих фреймворках чаще всего сами себе внушают что так и должно быть и это нормально - и рекламируют это другим...
    Это просто дурдом.
    Ответ написан
    15 комментариев
  • В какой последовательности читать книги по JS?

    @cluberr
    Книги по JS на русском и в каком порядке читать:
    1) Изучаем программирование на JavaScript
    2) Выразительный JavaScript
    3) JavaScript: сильные стороны
    4) Секреты JavaScript ниндзя
    5) JavaScript. Шаблоны
    6) JavaScript. Оптимизация производительности
    7) JavaScript для профессионалов
    8) ES6 и не только
    Ответ написан
    Комментировать
  • В какой последовательности читать книги по JS?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    За всю свою практику продолжительностью более 20 лет я прочитал только одну книжку по программированию, это был Фигурнов про программирование на паскале под ДОС, и это было в середине девяностых... С тех пор читаю только документацию и то по мере необходимости.

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

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

    В общем критерий истины - практика и никак иначе.

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

    Поэтому выбери себе проект, и начинай делать. Сначала будет все плохо, непонятно и вообще адский адов ад. И только если тебе хватит упорства и настойчивости, усидчивости, концентрации и везения, то, постепенно, все начнет меняться.

    Короче говоря ключевое слово тут ДЕЛАТЬ, а все остальное - лишь вспомогательные элементы.

    ЗЫ: Я встречал немало народу, почитавших книжек, прошедших курсов, знающих команды, но не умеющих их использовать, в результате не способных программировать. Для того, чтобы программировать, т.е. транслировать машине свою волю, на понятном ей языке, необходимо иметь эту самую волю для начала, а остальное уже приложится по ходу дела.
    Ответ написан
    3 комментария
  • Какие учебники по практическому применению JS и JQuery можете посоветовать?

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

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

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

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

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

    nikolayshabalin
    @nikolayshabalin
    Автор профессиональных курсов в HTML Academy
    https://habrahabr.ru/company/zfort/ - пользуюсь только этим, так как новостей становится всё больше и больше. Уследить за всем уже невозможно.
    Ответ написан
    3 комментария
  • Пример хорошего ТЗ/гайдлайна для вёрстки?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Основные требования: здесь
    Примеры стайл-гайдов: здесь

    1. Требования к вёрстке: здесь, здесь, здесь, здесь
    2. Как проверять качество вёрстки: здесь.
    3. Как определять стоимость (трудозатраты) вёрстки одной унифицированной страницы: здесь.
    4. Требования к дизайнеру: здесь и здесь.
    5. Пример документации (генератор шаблона, Helix3 для CMS Joomla!): здесь
    6. Готовые "скелеты" шаблонов HTML5 для начала вёрстки: простой (с поясняющими комментариями), www.initializr.com (ещё 3 простых) и максимально полный html5boilerplate.com.
    7. Вопросы на вакансию верстальщика (front-end developer): здесь

    Бонус по-теме: Turning Design Mockups Into Code With Deep Learning
    Ответ написан
    3 комментария