JavaScript *

В апреле посчастливилось побывать на очень крутом мероприятии — React Amsterdam. Кроме приятных организационных моментов было ещё и много интересных докладов. Они были, в основном, прикладного характера. Поскольку стек технологий в принципе устоялся, докладчики рассказывали о способах решения практических проблем, а не продвигали что-то незнакомое и революционное. Здесь я расскажу подробнее о выступлении “setState Machine” Микеле Бертоли из Facebook.

Основная проблема, которой был посвящен доклад, — сложность в управлении состоянием в React.

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

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

Если что-нибудь выше звучит интересно, или как минимум знакомо — добро пожаловать под кат.

HOC — слишком громкое слово для простого функционального паттерна!

Месяц назад в РайффайзенБанке прошел первый фронтенд-митап, и поскольку я всего за пару дней подготовил презентацию на тему «High order components with functional patterns using Recompose», а информацию о Recompose мельком выцепил в интернете за неделю до доклада, то не успел подготовить никакого справочного материала, и даже не написал своих контактных данных в конце презентации, что было не очень хорошо. И на вопрос: «Где мы можем увидеть ваши слайды?», я замялся и ничего не ответил, за что очень сильно извиняюсь.

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

Недавно мы презентовали решение для бизнеса, которое назвали Dialogflow Connector: связка из гугловского Dialogflow и нашего облака Voximplant. Коннектор может работать вместо оператора колл-центра и принимать сложные заказы. Это стало возможным, потому что Dialogflow позволяет уйти от сценария обычного IVR, где клиент вынужден называть слова из заданного набора, на который умеет реагировать интерактивное меню. Гугловская платформа может последовательно получать входные данные от клиента и собирать их воедино – например, чтобы сформировать заказ в интернет-магазине. Вероятно, вы уже слышали модное слово «slot filling», так вот это он и есть. Под катом вас ждут подробности, как мы делали бота для заказа пиццы – по аналогии вы можете запилить нечто похожее и возрадоваться, что времена лифта и «eleven» давно прошли…

Всем привет!

Версия Angular 2.0.0 вышла в сентябре 2016 г. И сразу же появилось большое количество подходов к построению и сборке приложений на этом фреймворке. На просторах интернета можно найти Angular seed на любой вкус.

Мы тоже создали свой Angular seed: создали общий project-template, обязали все команды, разрабатывающие фронт-энд, использовать одну структуру приложений.

А уже через полгода, в марте 2017 года, увидела свет версия Angular cli (cli – command-line interface) 1.0.0. Идея, взятая за основу, просто отличная: систематизировать подход к разработке приложений на Angular 2+. Стандартизовать структуру приложения, создание сущностей внутри приложения, а также автоматизировать сборку приложения. Эти задачи и позволяет решить Angular cli, значительно экономя ваше время.

В статье я покажу, как перейти на Angular cli 6

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

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



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

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

Уже очень давно у нас стоял вопрос: как же просто и быстро деплоить front-end проекта?

Мы думали насчет такого инструмента, как Jenkins. Многие, кто настраивал его, знают: настройка занимает немало времени и, что еще важно — затрачивается много ресурсов системы. Поднять его на сервере значит выделить полтора гигабайта памяти. Такое себе удовольствие, когда у тебя 500 мегабайт на всё, например.

Vue.js — это фреймворк, предназначенный для разработки веб-приложений. Он имеет систему реактивности, которая позволяет разработчику моделировать состояние приложения и управлять им. В результате, когда данные меняются, это автоматически отражается на пользовательском интерфейсе, при этом разработчику не нужно обращаться к DOM. Если вы создаёте приложения, пользуясь чистым JavaScript или jQuery, это значит, что вам приходится явно обращаться к элементам DOM и обновлять их для того, чтобы отразить в интерфейсе изменения состояния приложения, например, вывести на веб-страницу какие-то данные.

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

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

Язык — разумеется, JavaScript. Сама задача — классика, но ограничение в 50 символов обернулось настоящим челенджем.

В перерывах первого дня конференции мы обсуждали варианты достижения цели, постепенно сокращая ответ. Весь ажиотаж увенчался идеей поделиться задачей со всеми участниками конференции, и на второй день мы визуализировали задачу (см. приложение) и стали раздавать бланки желающим. В итоге получили около 40 решений и в очередной раз убедились в незаурядности сообщества js-разработчиков, но рекорд Дмитрия Катаева (SEMrush) в 53 символа остался. Давайте разбираться!

Я провел в играх сотни часов по статистике Стима, и тысячи, если считать на всех платформах. Но что меня поразило, так это соотношение времени в некоторых случаях. На прохождение великолепного Bioshock Infinite у меня ушло 8.5 часов, но на Sacura Clicker — на 12 минут больше. На Clicker Heroes — больше сорока часов, почти столько же, как на Torchlight 2. Фокус в том, что я помнил и хорошо представлял затраты времени на большие игры. Но маленькие игрушки совершенно не отложились в памяти, они украли мое время незаметно, растаскивая по пять-десять минут в течение недель и месяцев.

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

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

Материал, перевод которого мы сегодня публикуем, посвящён обработке JS-ошибок с помощью window.onerror. Это — особое событие браузера, которое вызывается при появлении неперехваченных ошибок. Здесь мы поговорим о том, как перехватывать ошибки с помощью обработчика события onerror, и о том, как отправлять сведения о них на сервер разработчика веб-сайта. Этот обработчик можно использовать в качестве основы собственной системы сбора и анализа информации об ошибках. Кроме того, он является одним из важнейших механизмов, применяемых в библиотеках, ориентированных на работу с ошибками, таких, как raven-js.

Привет!

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

jsFiddle — одна из самых популярных сред веб-разработки (работающая в веб-браузере), позволяющая редактировать и запускать код, написанный на HTML, JavaScript и CSS, который будет называться «фиддлом». Есть возможность использовать библиотеки для JavaScript, такие как jQuery.

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

Автор статьи, перевод которой мы сегодня публикуем, говорит, что её идею подсказал ему один из выпусков подкаста Syntax FM, в котором давался обзор полезных методов объектов и массивов в JavaScript. Эти методы помогают разработчикам писать чистый и читабельный код. Их применение снижает потребность в сторонних библиотеках наподобие Lodash.

Протокол SRTP (Secure Real-time Transport Protocol) это система безопасности, которая расширяет протокол RTP (Real-time Transport Protocol) набором защитных механизмов.

WebRTC использует DTLS-SRTP для шифрования, аутентификации и целостности сообщений, а также для защиты от атак повторного воспроизведения. Это дает конфиденциальность за счет шифрования RTP-нагрузки и проверки подлинности. SRTP это один из компонентов для безопасности, он очень удобен для разработчиков, которые ищут надежное и безопасное API. Но что такое SRTP и как оно работает?

Пролог

В настоящее время я занимаюсь разработкой редактора схем на Javascript, и в процессе этой работы столкнулся с проблемой, которой будет посвящена данная статья, а именно: сериализация и десериализация сложных объектов данных.

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

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

Подробнее о постановке задачи и ее решении под катом.

Что это такое?

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

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

При работе с базами данных существует проблема которую принято называть «SELECT N + 1» — это когда приложение вместо одного запроса к базе данных, который выбирает все необходимые данные из нескольких связанных таблиц, коллекций, — делает дополнительный подзапрос для каждой строки результата первого запроса, чтобы получить связанные данные. Например, сначала мы получаем список студентов университета, в котором его специальность обозначена идентификатором, а потом для каждого из студентов делаем дополнительный подзапрос в таблицу или коллекцию специальностей, чтобы по идентификатору специальности получить наименование специальности. Поскольку каждый из подзапросов может потребовать еще один подзапрос, и еще один подзапрос — колчество запросов к базе данных начинает расти в геометрической прогрессии.

При работе с graphql очень просто породить проблему «SELECT N + 1», если в resolver-функции сделать подзапрос к связанной таблице. Первое что приходит в голову — сделать запрос сразу с учетом всех связанных данных, но это, согласитесь, нерационально, если связанные данные не запрашиваются клиентом.

Один из вариантов решения проблемы «SELECT N + 1» для graphql будет рассмотрен в этом сообщении.