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

Владимир Матасов, выпускник курса Skillbox по веб-вёрстке, рассказал о своём опыте работы с плагином Emmet. Также подготовил инструкции по основным возможностям и командам для начинающих верстальщиков.

Привет, Хабр! Меня зовут Максим Васянович, я спикер курса “Веб-верстка” в Skillbox. Сегодня поговорим о верстке, а точнее - о нюансах работы с псевдоэлементами before и after. Статья будет полезна, прежде всего, начинающим верстальщикам. Но, возможно, и профи будет интересно освежить эти моменты в памяти. 

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

Ретиной называют дисплеи Apple с повышенной плотностью пикселей на квадратный дюйм. Впервые о них заговорили в 2010 году, когда Стив Джобс презентовал iPhone 4. Новый на тот момент смартфон получил экран с плотностью 326 PPI — в два раза выше, чем у его предшественника iPhone 3GS.

Ретина-дисплеи вывели смартфоны на новый уровень. По словам самого Стива Джобса, на ретина-дисплеях удалось достичь такого PPI, на котором человеческий глаз перестаёт различать отдельные пиксели. Текст стал выглядеть так, словно он выведен не на экран мобильного устройства, а напечатан в хорошей книге.

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

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

В этой заметке я бы хотел остановиться на различных нюансах, полезных при отладке. Какие-то из них я почерпнул в сети (например в комментариях на Хабре), до каких-то додумался сам. Надеюсь вы найдёте для себя что-нибудь полезное.

Под катом:

— Как отладить popup-ы, которые исчезают при потере фокуса
— Как убить повисший JS-цикл, не убивая вкладку
— Различные нюансы работы с breakpoint-ми
— Методы ведения войны с sourceMaps
— Перехват network-запросов
— Как отладить race-condition
— Почему стоит опасаться галочки "disable cache"
— Что делать если у вас не Hi-DPI экран?

Меня зовут Михаил Сахнюк и я разрабатываю фронтенд уже более шести лет. Сейчас я фронтенд разработчик в Miro. 

В статье рассмотрим:

• как оптимизировать веб-приложение и ускорить его загрузку;

• почему это важно;

• какие инструменты помогут в работе над оптимизацией, замерами и контролем результатов;

• преимущества работы с загружаемыми модулями в приложениях.

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

Статья — конспект моего доклада на конференции Mergeconf 2021 в Иннополисе. 

Эта статья для тех, кто только начинает свой путь в написании больших React приложений, но все еще использует только console.log для их дебага. Мы с вами рассмотрим работу с расширением для браузера "React Developer Tools" на простом примере, который в дальнейшем вы сможете применить в своих проектах. Это расширение дает возможность просмотра дерева компонентов, их props, состояния и контекста. Также достаточно просто отловить неэффективные компоненты, которые подвергаются повторному рендерингу, посмотреть сколько на это уходит времени и построить графики для визуализации эффективности компонентов. Благодаря этой информации вы не только сможете оптимизировать ваше приложение, но и более глубоко изучить React и понять все тонкости работы с ним.

Хочу поделиться личным опытом (об/м)учения в Яндекс.Практикуме на курсе "Веб-разработчик", и почему, вернувшись на год назад в прошлое, я бы никогда не стал там учиться даже за бесплатно.

Для начала расскажу о причинах, по которым я решил войти в IT (спойлер: и в итоге всё-таки вполз), и почему я выбрал именно Яндекс.Практикум.

Получив 2 красных диплома, которые теперь лежат на полке, я понял, что дипломированный инженер-строитель никому не нужен, т. к. с поиском работы по специальности в моём городе (областном центре) было тяжко. В итоге, отработав полгода рабочим на строительном комбинате и разочаровавшись в высшем образовании вообще и в своей специальности в частности, я задумался о смене профессии на более:

1) прибыльную (на комбинате я получал 24 тысячи в месяц);

2) перспективную (в IT действует меритократия, а в строительной сфере без связей, которых у меня нет, далеко на уедешь и высоко не взлетишь);

3) интересную и интеллектуальную. 

У меня есть старший брат – веб-разработчик с 10-летним стажем, за плечами которого опыт разработки в Яндексе, TopTal и нынешняя работа senior-программистом в Amazon. Я специально так подробно рассказываю о своём брате, т. к. далее эта информация понадобится для понимания контекста.

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

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

Быстрые сайты любят и пользователи, и поисковики.

С первыми всё просто: если страница долго грузится, пользователь её закроет и перейдёт на другой сайт. С поисковиками похожая история: скорость загрузки, скорее всего, влияет на ранжирование сайта в поисковой выдаче.

Lighthouse — один из известных инструментов для проверки производительности сайтов. Он тестирует сайт, показывает оценку производительности и даёт конкретные рекомендации: что можно улучшить, чтобы сделать сайт быстрее.

Lighthouse можно запустить тремя способами:

С помощью Node CLI. Для этого установите в свой проект пакет Lighthouse с помощью команды npm install -g lighthouse.

Через расширение для браузера Chrome или Firefox. Установите расширение, затем откройте свой сайт и запустите проверку с помощью кнопки Generate report.

С помощью инструментов разработчика — Chrome DevTools. Чтобы запустить проверку, откройте инструменты разработчика, переключитесь на вкладку Lighthouse и нажмите на кнопку Generate report.

Перед началом чтения пройдите простой тест — каким будет значение свойства background-color в первом и во втором варианте, и почему именно так?

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

p.s. Если у вас отключены картинки в ленте на Хабре, то сразу заходите под кат — тест дублируется и там.

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

Всем привет, это Макс Кравец из Holyweb. Знаю много историй, когда начинающего специалиста с первого дня бросают на задачи, за которые никто не берётся, и ждут, пока новый сотрудник сам «выплывет». А перегорит и уйдёт — значит, просто слабак, который не хочет работать.

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

Если вы — тот самый джуниор, хотите расти как IT-специалист и зарабатывать больше, но считаете, что вас постоянно недооценивают и держат на неинтересных задачах, ​​этот материал для вас.

→ Ссылка на github

Здесь я поделюсь своим опытом и постараюсь максимально подробно рассказать все основные фитчи которые есть в вашем javascript для обработки прикосновение к дисплею. touchstart и т.д.

Случай с бомжом

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

Обычно вместо денег я даю попрошайкам-мужчинам телефон отдела кадров одной курьерской компании, которая постоянно нуждается в сотрудниках. Но у него не было ног… Тогда я подумал: «Чувак, у тебя полным полно времени. Работа за компом — лучшее, что может случиться в твоей жизни. Купон со скидкой на курс по PHP — вот, что должны были положить тебе на койку туда, где раньше были ноги, когда ты очнулся после ампутации».

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

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

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

Привет, я Сергей Вахрамов, занимаюсь фронтенд-разработкой на Angular в компании Тинькофф. Во фронтенд-разработку вошел напрямую с тайпскрипта, просто перечитав всю документацию. С того момента и спецификация ECMAScript расширилась, и TypeScript сильно подрос. Казалось бы, почему разработчики могут бояться дженериков, ведь бояться там нечего? Мой опыт общения с джуниор-разработчиками говорит, что во многом ребята не используют обобщенные типы просто потому, что кто-то пустил легенду об их сложности.

Эта статья для тех, кто не использует generic-типы в TypeScript: не знают о них, боятся использовать или используют вместо реальных типов — any.

При разработке бизнес-логики приложений нужно продумать действия с множествами – с пересечением, разницей массивов или двойной разницей. Недостатки в этом алгоритме могут привести к рискам. Например, если вам нужно в реальном времени обработать объем данных, превышающий определенную границу, система может «тормозить» – до минуты и даже больше. Такие ситуации требуют лишнего расхода ресурсов, отталкивают пользователей и вызывают другие проблемы.

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