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

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

Неизвестный тимлид

Привет, Хабр! Представляю вашему вниманию перевод статьи «Data Visualization Libraries for React Developers in 2019» автора Veronika Rovnik.

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

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

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

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

За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).

В сегодняшнем выпуске.
Технологии внутри: Rust, TypeScript, JavaScript, Go, Python.
Тематика: веб разработка, инструменты для QA, работа с данными, инструменты разработчика и администратора.

Прошлый выпуск.

Давным-давно мы, в деле кэширования, всецело полагались на браузеры. Разработчики в те дни почти никак не могли на это повлиять. Но потом появились прогрессивные веб-приложения (Progressive Web App, PWA), сервис-воркеры, API Cache. Внезапно случилось так, что в руках программиста оказались широкие полномочия, власть над тем, что попадает в кэш, и над тем, как оно туда попадает. Теперь мы можем кэшировать всё, что хотим… в этом-то и кроется потенциальная проблема.



Медиа-файлы, в особенности — изображения, это то, что в наши дни является основной составной частью размера типичной веб-страницы. Со временем ситуация лишь ухудшается. Для того чтобы повысить производительность страниц, мы пытаемся кэшировать как можно большие объёмы подобных данных. Но стоит ли это делать? В большинстве случаев — не стоит. Даже учитывая то, что в нашем распоряжении теперь есть все эти новомодные технологии, нам, для того, чтобы достичь высокой производительности веб-страниц, всё ещё необходимо придерживаться одного простого правила. Оно заключается в том, что запрашивать с сервера нужно лишь то, что нужно, стремясь при этом к тому, чтобы в ответе на каждый запрос приходило бы как можно меньше данных.

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

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

Чаще прочих встречается вот такая алгоритмическая идея.

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

Одним из самых ярких событий в мире Фронтенда в этому году стала публикация репозитория Vue next — части функционала третьей версии VueJS. В этой статье представлен обзор новых killer features VueJS. На момент публикации статьи репозиторий находился в статусе Pre-Alpha. Планы на релиз можно посмотреть в Roadmap

Новый хабрапост в серии разборов недавно прошедшего чемпионата. Участникам квалификации, которые выбрали секцию фронтенда, нужно было решить несколько задач очень разной сложности: первая (по нашим ожиданиям) занимала 20 минут, последняя — около часа. Мы проверяли широкий спектр навыков разработчика интерфейсов, включая способность разобраться в необычной предметной области.

A. Аннигилируй это

^{Авторы: Максим Сысоев, Константин Петряев}

Первая задача — разминочная. Каждому участнику доставался один из четырёх вариантов задачи, похожих между собой. Мы предложили не только текстовое условие, но и «плохое» рекурсивное решение. Нужно было переделать код (написать жадный алгоритм, который выдавал самое быстрое решение), убрав рекурсию и разные глупости вроде лишних операций и вычислений.

Условие

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

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

Редактор Visual Studio Code (VS Code) стал восходящей звездой вселенной инструментов программирования сразу после того, как появился. Я долго не решалась его попробовать. Причина этого была не в том, что это — просто некий очередной редактор кода. Дело было в том, что вся моя работа была отлично организована в Sublime.



Для меня понятия «работа» и «написание кода» — это одно и то же. И, по большому счёту, неважно, каким именно редактором я буду постоянно пользоваться. Но изменения — это всегда нелегко. После того, как я неделю поработала в VS Code, я обнаружила, что моя продуктивность сильно просела. Я сделала за это время меньше, чем сделала бы, пользуйся я чем-то привычным.

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

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

Вот 10 возможностей VS Code, освоение которых помогло мне ускорить работу. Надеюсь, они пригодятся и вам.

Хочу рассказать про dap — интересный и необычный язык реактивных правил для написания, в частности, веб-фронтендов.

Для затравки простая задачка: взять список неких пользователей (воспользуемся тестовыми данными, любезно предоставляемыми сервисом jsonplaceholder.typicode.com) и вывести их имена обычным html-списком; при нажатии на имя пользователя — показать алерт с его id.

Это, конечно, легко делается и на React, и на Angular, и на Vue. Вопрос: насколько легко? В dap это делается так:

'UL.users'.d("* :query`https://jsonplaceholder.typicode.com/users"
 ,'LI'.d("! .name").ui("? .id:alert")
)

(*Этот и последующие dap-примеры можно интерактивно потестить в песочнице dap.js.org/test.html)

Это первая пришедшая в голову тривиальная задачка и тривиальный же способ ее решения. На dap удобно писать «в лоб», не городя огород из классов, компонентов и прочего ритуального реквизита. Что вижу, то пою. Но «пою» не на javascript или его производных, а на языке dap-правил, специально заточенном на простое и лаконичное описание реактивных зависимостей между элементами.

Недавно прошла HolyJS 2019 Moscow. На этой конференции я уже второй раз.

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

Статья будет интересна как уже бывалым участникам конференций, так и новичкам, ведь в этом году много нововведений.

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Axios — это широко известная JavaScript-библиотека. Она представляет собой HTTP-клиент, основанный на промисах и предназначенный для браузеров и для Node.js. Если вы работали в последние несколько лет JavaScript-программистом, то вы, совершенно определённо, этой библиотекой пользовались. В октябре 2019 года пакет Axios был загружен из npm 25 миллионов раз. Кажется, что будущее Axios безоблачно. Но что если я скажу вам, что Axios — это мёртвый проект. Именно этому было посвящено одно обсуждение на Reddit. А именно, речь идёт о следующем:

• В GitHub-репозитории Axios наблюдается весьма низкий уровень активности разработчиков.
• Проблемы и PR игнорируются.
• Команда разработчиков хранит молчание.

Ситуацию ухудшает и широко обсуждаемая уязвимость. Об этой уязвимости сообщено 2017 году. Авторы проекта игнорировали её более двух лет.

Когда библиотека Axios стала популярной, в браузерах не было API, реализующего HTTP-клиент, основанный на промисах. Стандартный интерфейс XML HTTP Request (XHR) был неудобным, работать с ним было тяжело. Разработчики с радостью приняли Axios из-за того, что эта библиотека облегчала им жизнь.



В 2015 вышел API Fetch. Почему же мы, в 2019 году, до сих пор используем Axios? Давайте сравним эти две технологии.

В нескольких эпизодах сериала «Мистер Робот» главный герой Эллиот взламывает и доксит своих жертв, записывая собранную информацию на аудио CD. Каждый диск он подписывает названием группы и альбома. Если злоумышленник получит доступ и поставит диск на воспроизведение — то услышит музыку, как и положено.

Судя по всему, Эллиот использовал программу DeepSound для сокрытия информации в звуковых дорожках. Это немного странно, потому что программа выпускается только под Windows, а хакер по определению не мог работать в этой операционной системе. Кроме DeepSound, существуют аналогичные инструменты для звуковой стеганографии. Например, QuickStego, AudioStegano, BitCrypt, MP3Stego, Steghide, AudioStego.

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

Привет, Хабр! Представляю Вашему вниманию перевод статьи «JavaScript in 3D: an Introduction to Three.js» автора Брета Кемерона (Bret Cameron).

Введение

Three.js это мощный инструмент. Он помогает использовать 3D дизайн в браузере с приемлемой производительностью. По началу Three.js может быть сложным, особенно если вы никогда не погружались в мир 3D программирования ранее.

У меня есть базовый опыт работы с игровым движком Unity и C#, но все равно многие концепции оказались новыми для меня. Я пришел к выводу, что сейчас совсем мало ресурсов для начинающих разработчиков, поэтому я и решил написать эту статью. В ней мы рассмотрим основные элементы Three.js сцены от полигональных сеток и материалов до геометрии, загрузчиков и много другого.

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

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

Если вы делаете Ctrl+C каждый раз при создании нового компонента в реакте, то эта статья точно для вас!

У реакта нет своего CLI, и понятно почему. Не существует определенных правил, как именно должна выглядеть структура компонента, есть только общие рекомендации в документации. Все разработчики используют структуру, которая прижилась в их команде. А иногда и вовсе приходится поддерживать проекты в разных стилях.

На связи Rambler Group. Можно просто Rambler.

В статье расскажем, как 5 ноября прошел открытый SberX RamblerFront& Meet Up.

Напомним, RamblerFront& — это митап, на котором наши сотрудники и друзья делятся прикладными знаниями в области frontend-разработки.

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

Освоение WebAssembly может оказаться непростым делом для веб-разработчиков. Однако ситуацию способен улучшить компилятор AssemblyScript.

Автор статьи, перевод которой мы сегодня публикуем, предлагает сначала поговорить о том, почему WebAssembly — это весьма многообещающая технология, а потом — взглянуть на то, как AssemblyScript может помочь в раскрытии потенциала Wasm.

«Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется», — Бьёрн Страуструп, создатель C++

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

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

Но действительно ли это так?

Как мы оказались в такой ситуации?

Не стоит ждать, что я назову JavaScript идеальным языком. У него есть странные причуды. Он был спроектирован за десять дней, а затем его изменили так, чтобы он напоминал Java. К сожалению, это наследие, с которым мы вынуждены жить.

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