В своей предыдущей статье я рассказывал про опыт использования движка Gemini для разработки визуальных тестов, точнее, тестов визуальной регрессии. Такие тесты проверяют, не «съехало» ли что-нибудь в UI после очередных изменений с помощью сравнения текущих скриншотов с ранее зафиксированными эталонными. С тех пор в наших подходах к написанию визуальных тестов многое изменилось, в том числе изменился и используемый движок. Теперь мы используем Hermione, но в данной статье я собираюсь рассказать не только и не столько о Hermione, сколько о накопившихся с того времени проблемах и способах их решения, которые в том числе привели и к переходу на новый движок.

Чем React Native отличается от Flutter, за исключением того, что речь идёт о разных фреймворках, в основу которых положены разные технологии? На что ориентироваться тому, кто не знаком с этими инструментами для разработки кросс-платформенных приложений, но хочет выбрать один из них для своего очередного проекта?



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

Здравствуйте. Изучая JavaScript (да и в принципе любую другую технологию), всегда возникают разнообразные вопросы, главный из которых: «А почему это работает таким образом и не иначе?» И очень важно в этот момент не просто найти ответ на вопрос, но и полученное объяснение встроить в единую систему уже полученных знаний. Иначе осиротевшую информацию придется зазубрить или забыть.

Совместное изучение чего-либо очень помогает искать ответы. Когда ученик / напарник задает вопрос про то, как понимать фразу — «… в следующий по цепочке промис „проваливается“ результат предыдущего… » — невольно задумываешься… Вот ведь какое странное дело. А ведь лучше уже не скажешь, неужели и это не понятно? Смотришь в чистые, немного наивные, глаза товарища и понимаешь — необходимо сказать как-то еще. Желательно так, чтобы даже запоминать не пришлось. Чтобы просто новая информация органично вписалась в уже существующие мысли человека.

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

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

Несколько месяцев назад я выступал на конференции FrontendConf 2019 с докладом Docker для фронтендера и хотел бы сделать небольшую расшифровку доклада для тех, кто больше любит читать, а не слушать.

Приглашаю под кат всех веб-разработчиков, особенно фронтендеров.

Привет, Хабр! Представляю вашему вниманию перевод статьи «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-правил, специально заточенном на простое и лаконичное описание реактивных зависимостей между элементами.

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

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? Давайте сравним эти две технологии.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всем привет!

Давненько на Хабре не было блог-постов от команды WebStorm. Что же, будем исправляться, тем более, есть отличный повод: мы только что выпустили последнее крупное обновление WebStorm в этом году.



Если у вас нет времени на чтение всей статьи, вот несколько слов о том, что появилось в WebStorm 2019.3:

• Мы проделали серьезную работу над ускорением запуска IDE, и теперь WebStorm 2019.3 отображает экран приветствия и открывает ранее проиндексированные проекты приблизительно на 20% быстрее по сравнению с предыдущими версиями.
• Благодаря автодополнению имен слотов, быстрой документации для символов Vue и поддержке компонентов, определенных в отдельных файлах, теперь вы можете создавать приложения с Vue.js еще быстрее.
• Существующую функциональность стало удобнее использовать: теперь вы можете автоматически включать глобальные средства просмотра файлов для всех новых проектов, быстрее клонировать проекты из GitHub и не только.
• Автодополнение кода для JavaScript и TypeScript стало еще умнее. Например, для новых переменных, функций, классов и интерфейсов WebStorm теперь подсказывает подходящие имена, которые уже использовались в той же области, но еще не были определены и отмечены как unresolved.

Это только часть улучшений. Чтобы попробовать их в деле, скачайте 30-дневную пробную версию WebStorm 2019.3 на сайте или с помощью Toolbox App. Полную версию могут использовать обладатели действующей подписки на WebStorm или All Products Pack, а также бесплатно студенты и разработчики проектов с открытым исходным кодом.

А сейчас давайте рассмотрим каждое из улучшений подробнее и пройдемся по другим важным изменениям в продукте.