JavaScript *

Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.

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

Одна из наиболее приятных возможностей React заключается в том, что эта библиотека не принуждает разработчика к строгому соблюдению неких соглашений, касающихся структуры проекта. Многое в этом плане остаётся на усмотрение программиста. Этот подход отличается от того, который, скажем, принят во фреймворках Ember.js или Angular. Они дают разработчикам больше стандартных возможностей. В этих фреймворках предусмотрены и соглашения, касающиеся структуры проектов, и правила именования файлов и компонентов.



Лично мне нравится подход, принятый в React. Дело в том, что я предпочитаю контролировать что-либо сам, не полагаясь на некие «соглашения». Однако много плюсов есть и у того подхода к структурированию проектов, который предлагает тот же Angular. Выбор между свободой и более или менее жёсткими правилами сводится к тому, что именно ближе вам и вашей команде.

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

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

Раймонд Джоунс "Уровень шума"

Dagaz появился не на пустом месте. Я всегда увлекался настольными играми и головоломками, а программированием занимаюсь сколько себя помню, но мысль о некоем «универсальном» движке просто не могла бы прийти мне в голову. К самой этой идее я относился скептически. Пока не увидел Zillions. К сожалению, продукт, на тот момент, уже не развивался, исходный код был недоступен, да и вообще, программа работала только под Windows. Спустя некоторое время, я решил взяться за открытый проект.

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

Есть заблуждение, что для создания своих железок требуется знать ассемблер, C/C++, уметь управлять памятью и глубоко понимать электричество. Когда-то так и было, но технологии развиваются и сейчас для полноценной реализации своего проекта достаточно только JS!



Ок, JavaScript мы знаем, а как соединить его с железом? Какое вообще бывает железо и что умеет? Как настроить всю систему? В расшифровке доклада Виктор Накорякова на FrontendConf узнаем: как, с помощью одного лишь JS, управлять сервоприводами, как физически объединить систему с PC, и о вариантах коммуникации приложения на JS. Обсудим пакеты serialport и Firmata, serialport с самописной прошивкой на C++, Espruino и программирование контроллера прямо на JS, Raspberry Pi, HTTP в локальной сети и HTTP и MQTT через облако.

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

Перевод JavaScript Environment, Lexical Scope and Closures.

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

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

Visual Studio Code (его ещё называют VS Code и VSCode) — это экономичный но мощный кросс-платформенный редактор кода, выполненный в виде настольного приложения. По словам автора материала, перевод которого мы сегодня публикуем, VS Code поддерживает множество инструментов разработки — вроде TypeScript и отладчика Chrome. Это, а также то, что к нему написано невероятное количество опенсорсных расширений, делает VS Code весьма популярным и любимым многими редактором.



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

Введение

В этой статье мы, как вы уже догадались, поговорим про Screen Capture API. Этот API появился на свет в 2014 году, и новым его назвать сложно, однако поддержка браузерами все еще достаточно слабая. Тем не менее его вполне можно использовать для персональных проектов или там, где эта поддержка не так важна.

Немного ссылок для начала:

• Спецификация Screen Capture
• MDN Usage Guide
• Демо

На случай если ссылка с демо отвалится (или если вам лень туда перейти) — вот так выглядит готовое демо:

Приступим.

Введение в ES6

Оглавление
1. Template literals
2. let and const
3. Arrow function expressions
4. For...of
5. Computed property names
6. Object.assign()
7. Rest parameters
8. Default parameters
9. Destructuring assignment
10. Map
11. Set
12. Classes
13. Promise
14. Iterators
15. Generators
16. Sumbol

Template literals (Template strings)

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

Шаблонные литералы заключены в обратные кавычки (` `) вместо двойных или одинарных. Они могут содержать подстановки, обозначаемые знаком доллара и фигурными скобками (${выражение}). Выражения в подстановках и текст между ними передаются в функцию. По умолчанию функция просто объединяет все части в строку. Если перед строкой есть выражение (здесь это tag), то шаблонная строка называется «теговым шаблоном». В этом случае, теговое выражение (обычно функция) вызывается с обработанным шаблонным литералом, который вы можете изменить перед выводом. Для экранирования обратной кавычки в шаблонных литералах указывается обратный слэш \.

Написано Kristofer Selbekk, в сотрудничестве с Caroline Odden. Основано на лекции с таким же названием и с теми же людьми, состоявшейся на встрече ReactJS в Осло в июне 2019 года.

От переводчика — оригинальное название The 10 Component Commandments не упоминает React, но большинство примеров и рекомендаций относятся именно к реакту, к тому же статья выложена под react тэгом и написана реакт разработчиками.

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

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

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

• Насколько маленьким может быть читаемый шрифт?
• Сколько памяти понадобится, чтобы его хранить?
• Сколько кода понадобится, чтобы его использовать?

Посмотрим, что у нас получится. Спойлер:

Привет, Хабр! Представляю вашему вниманию перевод статьи "Everything you need to know about Node.js" автора Jorge Ramón.

В наши дни платформа Node.js является одной из самых популярных платформ для построения эффективных и масштабируемых REST API's. Она так же подходит для построения гибридных мобильных приложений, десктопных программ и даже для IoT.

Я работаю с платформой Node.js более 6 лет и я на самом деле люблю её. Этот пост главным образом пытается быть путеводителем по тому, как Node.js работает на самом деле.

Материал, перевод которого мы сегодня публикуем, посвящён созданию динамических PDF-файлов с использованием HTML-кода в качестве шаблона. А именно, речь пойдёт о том, как сформировать простой счёт на оплату неких товаров или услуг, динамические данные, включённые в который, берутся из состояния React-приложения. База React-приложения создана с помощью create-react-app, серверная часть проекта основана на Node.js, при её разработке использован фреймворк Express.



Автор этого материала отмечает, что он подготовил видео, в котором демонстрируется разработка проекта. Если вы решите и посмотреть видео, и прочитать статью, то рекомендуется поступить так. Сначала бегло просмотрите статью, потом включите видео и воссоздайте у себя рассматриваемую там систему. А после этого просто прочитайте статью.

Самым важным для Frontend разработчика является модуль отображения в браузере, он же Rendering Engine (далее RE).

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

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

Весь прошлый год я работал с моим любимым фреймворком, Vue.js, описывал и представлял его. И я понял, что ещё не разобрался с обработкой ошибок во Vue. Мне бы хотелось объяснить это тем, что я пишу идеальный код, но мы все знаем, как обстоит дело в действительности. В течение нескольких последних дней я экспериментировал с различными методами обработки ошибок, которые предоставляет Vue, и решил поделиться своими открытиями. Очевидно, что этот обзор не охватит все возможные сценарии, но я надеюсь, что он вам поможет!

Райан Даль, создатель Node.js, потратил последние полтора года на работу над проектом Deno. Это — новая среда выполнения для JavaScript, которая должна исправить проблемы, присущие Node.js.

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

В его защиту можно сказать то, что он не мог знать о том, насколько популярной станет платформа Node.js за довольно короткий отрезок времени. Кроме того, в 2009 году JavaScript всё ещё выглядел как ограниченный и странный язык, над которым издевались все, кому не лень. Также надо отметить то, что в те времена многих возможностей JavaScript, привычных в наши дни, ещё не существовало.

Привет! Учусь на front-end, и параллельно, в учебном проекте, разрабатываю SPA на Vue.js для back-end, который собирает данные от поискового бота. Бот нарабатывает от 0 до 500 записей, и я должен их: загрузить, отсортировать по заданным критериям, показать в таблице.

Ни back-end ни бот, сортировать данные не умеют, поэтому мне приходятся загружать все данные и обрабатывать их на стороне браузера. Сортировка происходит очень быстро, а вот скорость загрузки, зависит о коннекта, и указанные 500 записей могут загружаться от 10 до 40 секунд.

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

Чтобы скрасить пользователю ожидание, я решил показать ему процесс загрузки:

1. цифрами — сколько % записей уже загружено
2. графиком — время загрузки каждой записи
3. заполнением — % загрузки. Так как график по мере загрузки заполняет прямоугольный блок, видно, какую часть блока осталось заполнить

Вот анимация результата, к которому я стремился и получил:

… по-моему, получилось забавно.

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

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

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

Все эксперименты приводимые далее проверялись в Chrome и Firefox может быть даже не самых новых версий.

Автор материала, перевод которого мы публикуем сегодня, занимается работой над фреймворком Quasar. Это — полнофункциональный расширяемый опенсорсный инструмент для разработки современных приложений различного назначения. Он построен на базе популярного фронтенд-фреймворка Vue.js и использует возможности Node.js, Webpack и Babel. Совсем недавно, в начале июля сего года, вышел первый стабильный релиз Quasar.