Обычный, теневой, виртуальный, инкрементальный… Как получилось, что простой программный интерфейс доступа к элементам веб-страниц обзавелся таким количеством «родственников»? Чем современные фреймворки не устраивает стандартная объектная модель документа или просто DOM? Что и как на самом деле отрисовывает браузер в процессе рендера веб-страницы?

Всем привет, это Макс Кравец из Holyweb. Помните сцену из Матрицы, в которой один из юных кандидатов в Избранные наставляет Нео: «Не пытайся согнуть ложку. Первое, что ты должен понять — ложки не существует!»? Давайте переформулирую: «Не пытайся изменить DOM...». А вот о том, что прячется под многоточием, мы сегодня и поговорим.

Привет, друзья!

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

Функционал нашего приложения будет следующим:

• запись аудио
• отображение записи с возможностью ее предварительного прослушивания и последующего сохранения или удаления
• хранение аудио-файлов на сервере
• извлечение аудио-файлов, хранящихся на сервере, и их отображение в браузере

Основная технология, которую мы будем использовать, это MediaDevices. Данная технология входит в состав глобального объекта Navigator. Основным методом, предоставляемым указанным интерфейсом является getUserMedia(). Запись данных (в простых случаях вроде нашего) выполняется с помощью интерфейса MediaRecorder.

Интерфейс MediaDevices на сегодняшний день поддерживается всеми современными браузерами.

Для небольшой стилизации нашего приложения мы будем использовать Sass.

Выглядеть приложение примерно так:

Исходный код приложения.

Основным источником вдохновения для меня послужила эта замечательная статья.

Обратите внимание: данная статья рассчитана, преимущественно, на начинающих разработчиков, хотя, смею надеяться, что и опытные найдут в ней что-нибудь интересное.

Вы готовы? Тогда вперед!

Недавно мы выпустили статью «Дефицит в IT: платите больше» о росте зарплат. Совпадение или нет, но чуть позже вышла статья о минусах большого заработка у российских айтишников. Автор рассуждал о том, как высокие зарплаты могут навредить IT-отрасли. На первый взгляд аргументы выглядят логично. Но это только на первый взгляд.

Привет, Хабр!

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

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

Можно ли на него ответить?

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

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

Краткое содержание: проверка кода по стандартам, проверка вёрстки и стилей, работа с кодом, работа с графикой (SVG, фавиконки, конвертеры и сжималки), работа с текстом (типографы и конвертеры всего во всё).

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

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

Фавиконки — ответственность верстальщика. Под катом рассказ о том, как подключить обязательную фавиконку и каким должен быть набор иконок, как использовать иконки в SVG, что нужно дополнительно сделать для устройств от Apple, и почему хорошо использовать webmanifest для подключения всех фавиконок к вашему сайту.

Привет, Хабр! Немного запоздало (ко дню программиста) делюсь подборкой бесплатных книг по программированию. Все они полезные, уровень скорее профессиональный, хотя и для развития от базового тоже подойдет, но, к сожалению, на английском. Среди тем книг: .NET, Алгоритмы, Android, iOS, Angular, C, C++, C#, JS, Linux, Python. В целом, найдется почти любая тема, которая приходит в голову.

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

Привет! Меня зовут Дима Чудинов, я наставник на веб-факультете Яндекс.Практикума, Head of Group, Front-end, ABBYY.

Студенты недавно задали мне вопрос: «Что лучше: Angular или React?». Я начал отвечать и понял, что мне понадобится для этого статья. Позже я понял, что и одной статьи не хватит.

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

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

Чтобы всё не запороть с самого начала, можно попробовать воспользоваться рекомендациями, которые изложены в этой статье. Они относятся к трём основным аспектам хорошего дизайна: работа с формами, типографика, композиция. Воспользовавшись этими рекомендациями вы не станете отличным дизайнером, но сможете избежать неприятных ошибок, способных свести продукт в могилу. А заодно узнаете немного нового про дизайн и просто начнёте немного лучше разбираться в UI/UX.

Вашему вниманию предлагаю перевод статьи Sacha Greif "Что же такое этот GraphQL?"

Если вы такой же, как и я, вы обычно проходите через три этапа, когда узнаёте о новой технологии:

• Отрицание: Ещё одна JavaScript библиотека?! Зачем? У меня уже есть jQuery!
• Интерес: Хм, наверное мне следует взглянуть на эту библиотеку...
• Паника: Помогите! Мне нужно изучить эту библиотеку прямо сейчас, иначе мои знания устареют!

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

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

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

Большинство предложений разбивались о какие-то специфические особенности Хабра и ситуации, которые изначально не брались в расчёт. Иногда присутствовало здоровое зерно логики. Встречались и чрезмерно сложные фантазии. Мы читали каждый такой пост и комментарии к нему, мотали на ус, делали какие-то расчёты, но всё же не спешили вносить изменения. В функцию, которая может и не идеально, но всё же 15 лет проработала основой пользовательской регуляции.

Но сегодня мы анонсируем два изменения в механизме кармы.

var f = function() {
    this.x = 5;
    (function() {
        this.x = 3;
    })();
    console.log(this.x);
};

var obj = {x: 4, m: function() {
    console.log(this.x);
}};


f();
new f();
obj.m();
new obj.m();
f.call(f);
obj.m.call(f);

Очередная история успеха после череды неудач. Расскажу, чего мне стоило получить офферы от Facebook*, Google, Amazon, JP Morgan в Европе, как я готовился, сколько собесов зафейлил перед тем, как удача повернулась ко мне правильной стороной.

TL;DR. Послал сотни резюме. Прорешал около 100 задач на Leetcode. Прочел книжку по архитектуре (не той, которая про дома, а той, которая system design). Прошел 9 интервью. Получил 4 оффера. Принял 1. Жил, пока что, не очень долго, но, вполне себе, счастливо в Лондоне.

Ой, а напомни как называют очень опытного программиста, там что-то такое романтично-средневековое, кажется «милорд»...

Почти три года назад на Хабре вышла статья «Фулстеки — это вечные мидлы. Не идите по этому пути, если не хотите страдать». Я еще тогда был не согласен с изложенным, но сдержался:) Однако недавно я стал свидетелем весьма примечательного случая и сразу вспомнилась та самая статья... Итак, одна команда испытывала нехватку бекенд-разработчиков и сравнительный переизбыток раработчиков на фронте. Дело осложнялось сжатыми сроками сдачи проекта. Проблема типовая, но стек..., ах если бы не стек: бек — NodeJs, фронт — React, TypeScript и там и там.

Я не хочу отрицать важность специализации вообще, но в данном конкретном случае ответ очевиден: нужно перебросить кого-то с фронта на бек. Да, это будет неэффективно, да скорее всего в бекенд-коде, который напишет фронтендер будет больше проблем, но альтернатива то еще хуже: часть команды будет зашиваться, пока другая — простаивать. Если вы дочитали до этого места и уже готовитесь написать гневный комментарий о том, что «бекенды же бывают разные и в том числе такие сложные, что ваще капец и такой финт ушами не пройдет и только всех замедлит и сделает еще хуже», то не спешите не сдерживайтесь, пишите прямо сейчас (больше мнений в комментах!). Так вот, это был простой бекенд пишущий и читающий в/из базы данных. Никаких особенно сложных штучек-дрючек там не было...

Может быть я старомоден, но сегодняшняя специализация порой видится мне чрезмерной. Раньше все было как-то проще: ты либо умеешь программировать, либо нет. А сейчас все кругом ищут кибер-ниндзю с опытом работы исключительно на фреймворке X не менее пяти лет (хотя фреймворк X существует четыре года). Если ты работал с фреймворком X всего три года, то с тобой не о чем разговаривать: ты — джун. Ага, т.е. известному английскому банку не впадлу нанимать на Java-проект кандидата с десятилетним опытом на .NET’е, потому что они считают, что важны фундаментальные знания, а не знания конкретной платформы (ну напорется он пару раз на стирающиеся дженерики и сравнение строк через ==, почешет репу и перестанет так делать), а ООО «Рога и Копыта Интернейшнл» может работать только с теми, кто пять лет ковырял фреймворк Х. По-моему это фигня. Кстати, тот парень в банке, что перешел с .NET'а на Java сейчас там числится синьором и находит горы проблем в мердж-реквестах разработчиков, пишущих на Java значительно дольше него.

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

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

Всем привет, меня зовут Иван, я – разработчик ПО в Orion Innovation. Сейчас много публикаций по фронтенд-разработке, в которых начинающему специалисту легко потеряться и упустить неочевидные вещи.

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

После прочтения ряда статей (например, этой) решил перейти на современный подход с использованием Node.js при написании простых сайтов с подхода «динозавров». Ниже представлен разбор примера сборки простого статического сайта с помощью Webpack 4. Статья написана, так как инструкции с решением моей задачи не нашел: пришлось собирать всё по кусочкам.