• В чем смысл ВУЗа?

    @Programmir
    Я окончил школу с золотой медалью, получил высшее образование на факультете менеджмента, а теперь с этой корочкой даже продавцом не берут. Столько лет зря потратил. Учись на чужих ошибках. Чтобы заработать миллиарды Гейтсу и Цукербергу не нужно было высшее образование. А некоторые с высшим образованием за копейки не могут найти работу.
    Ответ написан
    13 комментариев
  • В какой последовательности читать книги по JS?

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

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

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

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

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

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

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

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

    @azShoo
    Для начала давайте разберемся, что же такое QA? Понятие это довольно абстрактное, и в СНГ применяется зачастую в ином понимании, нежели в краях более отдаленных.
    QA - это обеспечение качества продукта, причем, в идеальном случае, на всех этапах разработки.
    Самое первое, с чем придется в большинстве случаев столкнуться QA Engineer`у это функциональное тестирование.
    Написание тестов по задачам и прохождение этих тестов., прохождение уже написанных, апдейт, заведение багов и прочее. В этом случае QA Engineer = Тестировщик. Для этого самое важное - хорошо работающая голова, умение читать задачи и задавать правильные вопросы: "А что если так? А если этак?".
    В зависимости от продукта требуются дополнительные скиллы -> в вебе своя специфика, в мобильных своя, в по - своя, в железе - своя. Ну и соответственно базовое понимание кода, работа с базой данных и прочее - тоже периодически понадобятся.

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

    Отдельная часть - автоматизация тестирования. Здесь от компании к компании все по разному, и роль автотестера варьируется от "тестера который научился использовать тестовый фреймворк" до "полноценного разработчика, который автоматизирует то, что ему говорят тестировщики".
    Требования отличаются соответственно.

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

    Что в итоге?
    Мне кажется, что QA-инженер это тестировщик, который вышел в своей работе за рамки тестирования. Который работает над качеством продукта не только в плане "Требования выполнены - к продакшену готовы", а старается делать продукт лучше во всех отношениях, в первую очередь - для бизнеса, во вторую - для пользователя, в третью - для тех, кто этот продукт делает.
    Следовательно, я считаю что путь QA лучше всего начинать именно с тестирования (кстати говоря, в России понятия QA и тестирования почти всегда тождественны в умах не-тестировщиков).
    Что важно для тестировщика?
    Способность и желание разбираться в том, как это [продукт\фича\пр] работает сейчас, и как это должно работать.
    Так же стоит приготовиться много говорить "нет, так не пойдет" менеджерам и разработчикам.
    Ну и вообще, смириться с тем, что другие стороны процесса очень часто готовы действовать в ущерб качеству.

    Что хотят, что бы знал джуниор?
    1) представление о процессе разработки. Этапы, когда пора тестировать и все такое.
    2) представление о написании тестов: что представляет из себя тест-план, тест-сьют, тест-кейс, тест-степ, Definition of Done, Ожидаемый результат и тд.
    3) представление о том, что такое дефект: Severity и Priority дефектов, какие бывают; из чего состоит описание дефекта, и все такое.
    4) хотя бы общее представление о тест-дизайне: что такое, зачем нужен, какие есть практики.
    5) Базовые навыки SQL - селект, упдейт, работа с несколькими таблицами и все такое.
    А ещё хотят, что бы человек умел думать. Будь готов к задачкам на логику (которые туфта и ненужны) и к задачкам типа "Есть окно с кнопкой, посылает запрос: напиши тесткейсы" или "Протестируй карандаш".

    Как-то так.
    К сожалению, больше рассказал именно о тестировании, чем о QA в целом. :)
    Ответ написан
    2 комментария
  • Как правильно учить Javascript?

    IonDen
    @IonDen
    JavaScript developer. IonDen.com
    Вы наверное слышали, что каждый уважающий себя программист обязан написать несколько велосипедов? И JavaScript-программисты тоже так делают и еще как! Так вот в этом нет ничего плохого, это отличное самообучение.

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

    Не пытайтесь брать сразу сложные вещи, начинайте с малого. Как заметили выше, не смотрите пока что на очень сложные книжки, их читать сейчас почти бесполезно.
    Ответ написан
    6 комментариев
  • Счетчик кликов на js?

    Petroveg
    @Petroveg
    Миром правят маленькие с#@&ки
    Есть механизм localStorage. Подключений библиотек не требует. Поддерживается везде.
    if (window.localStorage) {
    	var value = localStorage.getItem('count'),
    		newvalue = isFinite(value) ? ++value : 0;
    
    	localStorage.setItem('count', newvalue);
    	console.log(newvalue);
    }
    Ответ написан
    Комментировать
  • Как понять принципы ООП?

    onqu
    @onqu
    weasy
    Чтобы понять принципы ООП, книги не требуются. Взгляните вокруг себя. Всмотритесь в любой объект в реальном мире, опишите его наиболее подробно (материал, размер, цвет, вес, плотность, составные части и т.д.), это будут его свойства. Опишите, что и каким образом этот объект умеет делать (включаться, складываться, кушать электроэнергию, взаимодействовать с другими объектами или окружающей средой и т.д.), это будут его методы. Подумайте, для чего используется этот объект, что ему нужно изменить или добавить, чтобы использовать в других условиях или целях, и на основе всех собранных знаний создать более удобный экземпляр, это будет наследование и полиморфизм. Теперь немедленно забудьте обо всем, используйте объект по назначению, это будет инкапсуляция. Дальше останутся только тонкости выбранного Вами языка, шаблоны, методологии и прочаяие ересь тренды.
    Ответ написан
    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 комментариев
  • Как изменить глобальную переменную?

    Tizi
    @Tizi
    гуру программист ( no )
    Я реализовал это так ))) Клик
    Ответ написан
    5 комментариев
  • Из математика в front-end разработчика. С чего начать?

    SKolt
    @SKolt
    https://www.instagram.com/seregamih/
    Хорошо там, где нас нет :) Если поискать темы, здесь тоже создавались, то такие же вопросы задают и front-end-щики. Переквалифицируетесь и потом тоже будете писать, что это:

    больше занятие для души, нежели способное хоть как-то обеспечить.

    Как раз таки на занятиях для души люди больше всего и зарабатывают. Надо только придумать, что продать и кому.
    Ответ написан
    Комментировать
  • Какие знания о JavaScript необходимы чтобы считаться junior/middle/senior developer'ом?

    fr_end
    @fr_end
    Frontend разработчик
    Сложилось впечатление, что у каждой компании свои критерии, и все это деление на квалификации нужны для того, чтобы разработчик чувствовал свой рост.
    Есть знакомый, который в одном месте поднялся до сеньора за полтора года, а потом в другое, по той же специальности, его даже миддлом не взяли.
    Так что спрашивайте в самих компаниях, какие у них требования
    Ответ написан
    Комментировать
  • Codewars, на сколько поможет подтянуть js?

    Jump
    @Jump
    Системный администратор со стажем.
    Скажите, реально ли по codewars прокачаться по js
    Реально.

    Скажите, реально ли по codewars прокачаться по js до уровня среднестатистического front end разработчика?
    Нереально, ибо к front end разработке он никаким боком не относится.

    JS это инструмент. Как молоток, или пила. И им нужно уметь пользоваться.
    Но хорошее умение пользоваться молотком и пилой не сделает вас умелым плотником. Ибо это только часть умения, необходимая, но не исчерпывающая.
    Ответ написан
    Комментировать
  • Как (и возможно ли) дотянуться до Junior JavaScript Developer в кратчайшие сроки?

    webinar
    @webinar
    Учим yii: https://youtu.be/-WRMlGHLgRg
    есть не-айти вышка и кандидатская (естественные науки)

    ну так всё. Что еще надо? К чему это? А у меня есть дома гитара.

    Москва

    В Москве конечно же книги лучше читаются, чем в Твери, например.

    Сделала для знакомых большой (но статичный) сайт с адаптивной версткой, все элементы реализовала сама (без готовых решений, чистый CSS/JS).

    Очень много спама, достаточно было ссылки и "что вы думаете, ребята?"

    Возможно ли за это время дотянуться до Junior JavaScript Developer?

    Да, тут все зависит от человека. Качество работы мозга у Всех разное, а у некоторых в 30 это уже статическая серая масса. Но Вас видимо это миновало, раз есть желание все менять.

    Что от них хотят?

    Что бы они дешево работали

    углубляться в "голый" JavaScript или разбираться с frameworks (какую выбрать?) и базами данных? Или вообще хватит умения обращаться с AJAX?

    Все вместе с упором на "голый" JavaScript

    Или это всё утопия, а начинать всё равно придётся с позиции верстальщика?

    Тут дело не в Вашем скиле, а в рынке. Верстальщиков много, как и задач по верстке. Большинство компаний лепят гов.но, сорри, сайты на wp, собирая из готовых шаблонов и плагинов. Так что тут проблема в том, что найти позицию именно frontend спеца будет сложно не зависимо от скила. Но возможно.
    Ответ написан
    Комментировать
  • Как в pug вывести одинаковые блоки с разным содержимым?

    vicodin
    @vicodin
    Имею некоторый опыт
    Ответ написан
    Комментировать
  • Как сверстать такую таблицу из логотипов?

    @ZENbZ
    Начинающий веб-разработчик, чуточку программист
    Как вариант тыц
    Ответ написан
    Комментировать
  • А не поможете с Flexbox и IE11?

    bootd
    @bootd Куратор тега CSS
    Гугли и ты откроешь врата знаний!
    В IE11 нельзя прижимать футер при помощи flexbox с использованием min-height: 100%, т.к. все дочерние элементы не видят этой высоты. От чего и получается, что один наезжает на другой. Это баг самого браузера.

    В данном случае это реализовано у блока .container
    Ответ написан
    Комментировать
  • Что почитать для «посредственного» js разработчика?

    iCoderXXI
    @iCoderXXI
    React.JS/FrontEnd engineer
    Язык программирования, это инструмент, по типу молотка или кухонного комбайна.

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

    Понятно что инструментом желательно владеть виртуозно. Но одного инструмента категорически недостаточно. Глупо считать, что выучил JS и все, можно покорять вершины. Для начала имеется немалое количество сопричастных технологий, да хоть те же HTML+CSS, DOM, браузеры с их нюансами и API, HTTP, Ajax, Rest, алгоритмы и структуры данных, хранилища, и еще миллион всего.

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

    В общем совет тут такой уже давали, выше, но не объяснили почему. Так вот, надо тупо делать. Набивать руку, так сказать. По мере деланья придется со всем этим зоопарком, так или иначе, познакомиться. Через, примерно, тысячу часов уже в голое сложатся базовые паттерны, что там к чему, как, зачем и почему. Сначала будет "Ну ваще ничего нипаняятнааа", и это нормально. Декомпозируешь большое и сложное на более мелкое и не такое страшное, и делаешь что можешь. Остальное снова декомпозируешь и так далее. И гуглишь, гулишь, гуглишь, гуглишь, гуглишь... Ну ты понял.

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

    ЗЫ: Если не владеешь инглишем в достаточной степени, чтобы свободно понимать устную речь и тексты, то я тебе, в общем то, не завидую...
    Ответ написан
    Комментировать
  • Как лучше организовать структуру медиа запросов и стилей?

    EaGames
    @EaGames
    Front-end developer
    Мне не нравится искать в одном файле 4 места где определяются стили для одного и того же блока, по этому я делаю все рядом.
    .some-block {
    	width: 1000px;
    	@include desktop {
    		width: 100px;
    	}
    	@include tablet {
    		width: 10px;
    	}
    	@include mobile {
    		width: 0px;
    	}
    }
    Ответ написан
    Комментировать
  • Почему ошибка останавливает выполнение других скриптов?

    @BorisKorobkov
    Web developer
    Почему ошибка останавливает выполнение других скриптов?

    Вспомните мультфильм "Клад кота Леопольда". Там надо было сделать "пять шагов на север от старой березы", то есть
    1. найти старую березу
    2. определить север
    3. сделать 5 шагов

    Если старая береза не найдена, то последующие действия не имеют смысла.
    Так и в js.

    Я хочу, чтобы ниже подключенные файлы всегда исполнялись.

    https://habrahabr.ru/company/mailru/blog/282149/
    Ответ написан
    Комментировать
  • Как делаются подобные сайты?

    profesor08
    @profesor08
    Именно в этом сайте задний фон сделан довольно просто, и без всей той херни, которую тебе насоветовали выше.
    prntscr.com/jalr34

    На заднем фоне блок, залитый градиентом. При прокрутке меняется позиция фона и получается такой эффект. Аналогично получится, если растянуть этот блок не на размер экрана, а на весь контент. И js не потребуется, если не хочешь управлять скоростью смещения фона с градиентом.
    Ответ написан
    Комментировать