JavaScript *

Пять лет назад на Хабре была опубликована статья «Печать и воспроизведение звука на бумаге» — о системе создания и проигрывания спектрограмм. Затем, полтора года назад Meklon опубликовал квест, в котором такая чёрно-белая логарифмическая спектрограмма стала одним из этапов. По авторскому замыслу, её надо было распечатать на принтере, отсканировать смартфоном с приложением-проигрывателем, и воспользоваться таким образом «надиктованным» паролем.


У меня в тот момент не было в досягаемости ни принтера, ни смартфона, так что меня заинтересовали два аспекта задачи:

1. Как проще всего расшифровать спектрограмму без дополнительных устройств и без дополнительного софта — желательно, прямо в браузере?
2. Можно ли её расшифровать вообще без софта — «на глаз»?

На FrontendConf в этом году будет выступать Leonie Watson — евангелист доступности, и Andy Bell — широко известный в мировом фронтенд-сообществе автор электронной книги «Every Layout». Выступление Leonie будет нестандартным и технически сложным, когда зрение участников будет не самым важным чувством. Andy и Leonie пригласил Павел Ловцевич. Он организует конференции в Минске, приглашает иностранных спикеров на свои конференции и к нам на FrontendConf, курирует доклады и все это, не считая работы техническим директором.



Накануне FrontendConf мы поговорили с Павлом о его роли в программном комитете конференции, о приглашении иностранных докладчиков, доступности, CSS и Grid Layout, usability презентаций, неочевидных мелочах, особенностях работы куратора, а в конце — почему вообще важно посещать конференции.

Моё имя Азат Разетдинов, я в Яндексе уже 12 лет, руковожу службой разработки интерфейсов в Я.Недвижимости. Сегодня я хотел бы поговорить про монорепозиторий. Если у вас всего один репозиторий в работе — поздравляю, вы уже живете в монорепозитории. Теперь о том, зачем он нужен другим.

Как сказала руководитель службы разработки API Яндекс.Карт Марина Перескокова — посадил дед монорепу, выросла монорепа большая-пребольшая.

Disclaimer: да, в понедельник мы опубликовали хабрапост с именно таким сравнением языков. Нет, мы не сошли с ума. Всё идёт по плану.

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

Эта хабрастатья — большое интервью с Виталием на следующие темы: 

• Преподавание и знакомство с JavaScript;
  
• Зачем выбирать Haskell;
  
• Место функциональных языков в жизни программиста;
  
• Чего хорошего в JavaScript и как он развивается;
  
• Что появится в языках программирования в ближайшие 10-15 лет;
  
• Какие языки программирования вызывают доверие и почему;
  
• В чем разница между научными конференциями и конференциями для разработчиков. Зачем преподавателю вообще на них ходить;
  
• Важно ли читать программисту, устаревают ли книги и какие из них must read.
  

Интервью ведут члены Программного комитета конференции HolyJS 2019 Moscow, Алексей Золотых и Артём Кобзарь. Если интервью вам недостаточно, то уже совсем скоро, на следующей HolyJS, Виталий расскажет и покажет на примерах, как связать JavaScript с теорией алгоритмов. 

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



Материал, перевод которого мы публикуем сегодня, посвящён рассказу решении проблемы с производительностью Moment.js.

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

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

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

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

При разработке приложений «фронтендеры» редко обращают внимание на то, как пользователь будет использовать предоставляемые браузером функции клавиш. Я не являюсь исключением, но в один день мне была дана задача касаемо UX и переходов с помощью нажатия «Tab» и «Shift + Tab».

Суть задачи прозрачна и чиста: есть интерфейс, макет которого отображен ниже. Концептуально 1 страница может содержать 2 различные формы и требованием было условие, чтобы «бегание „Tab`ами“ не переходило с 1 формы на другую».

Голосовые помощники — не далёкое будущее, а реальная действительность. Alexa, Siri, Google Now, Алиса встроены в «умные» колонки, часы и телефоны. Они постепенно меняют наш способ взаимодействия с приложениями и устройствами. Через ассистента можно узнать прогноз погоды, купить билеты на самолет, заказать такси, послушать музыку и включить чайник на кухне, лежа на диване в другой комнате.



Siri или Alexa говорят с пользователями в основном по-английски, поэтому в России они не так популярны, как Алиса от Яндекса. Для разработчиков Алиса тоже удобнее: её создатели ведут блог, выкладывают удобные инструменты на GitHub и помогают встраивать ассистента в новые устройства.

Никита Дубко (@dark_mefody в Твиттере) — разработчик интерфейсов в Яндекс, организатор митапов MinskCSS и MinskJS и редактор новостей в Web-стандартах. Никита не работает в Яндекс.Диалогах и никак не связан с Яндекс.Алисой. Но ему было интересно разобраться, как Алиса работает, поэтому он попробовал применить её навыки для Web и подготовил об этом доклад на FrontendConf РИТ++. В расшифровке доклада Никиты рассмотрим, что полезного могут принести голосовые помощники и построим навык прямо в процессе чтения этого материала.

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



→ Читать, затаив дыхание, первую часть

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

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

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

На самом деле всё это может занять у вас меньше часа. Без знаний DevOps и совершенно бесплатно.

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

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



Сущность void имеется также в JavaScript и TypeScript. В JS это — оператор. В TS это примитивный тип данных. И там и там void ведёт себя не так, как могли бы ожидать многие из тех, кто сталкивался с void в других языках.

Вместо предисловия

Данный пост является ответом на вчерашнюю статью «Боль и слёзы в Svelte 3» и появился как следствие сильно «располневшего» комментария к оригинальной статье, который я решил оформить в виде поста. Ниже я буду использовать слово автор для отсылки к автору оригинальной статьи и позволю себе сделать некоторые уточнения по всем пунктам. Поехали!

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

Всем привет!

В этой заметке я хотел бы поделиться своим подходом к организации и тестированию кода с использованием Redux Thunk в проекте на React.

Путь к нему был долог и тернист, поэтому постараюсь продемонстрировать ход мыслей и мотивацию, которые и привели к итоговому решению.

Вместо предисловия

Статья будет полезна тем, кто так-же как и Мы решил попробовать Svelte в живом проекте. В нашу небольшую компанию пришёл заказ на разработку веб-админки для сервиса с бекэндом на Mongodb Stitch. В последние пару лет frontend Мы пишем на React или Vue (в зависимости от размера проекта и нужен ли ReactNative), но наслышав о красотах Svelte мы решили попробовать его, чтобы понять для себя так ли он хорош. И может нам тоже стоит дальше использовать его вместо Vue или React?..

Кто такой Svelte?

Если в двух словах — это новый js фреймворк (но он таким себя не считает), который убийца React и Vue, и бла, бла, бла… В своей статье я хочу рассмотреть Svelte не какой он классный «под капотом», а с точки зрения удобства его использования в реальном проекте.
Мы не делаем машины, мы на них ездим и у нас есть злые заказчики с еще не менее злыми сроками.

Технология веб-сокет позволяет в веб-приложении или в мобильном приложении реализовать отправку сообщений с сервера на клиент, что невозможно сделать средствами REST-API. Для работы с веб-сокетами часто используют библиотеку socket.io, или же разработчики работают с нативными объектами веб-сокет браузеров. В этом сообщении я попытаюсь показать, что оба пути не решают всех проблем, и гораздо лучше использовать для работы с веб-сокетами специализированные серверы, например mqtt-сервер (раньше его назвали mqtt-брокер).

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

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

В предыдущей статье мы рассматривали общую теории ООП в применении к EcmaScript и популярное заблуждение начинающих разработчиков относительно отличия ООП в JS и классических языках.

Сегодня мы поговорим о двух других не менее важных концепциях EcmaScript, а именно связи сущности с контекстом исполнения (this и есть эта самая связь) и связи сущности с порождающим контекстом(ScopeChain).

Итак, начнём!

this

На собеседованиях в ответ на вопрос: «Расскажите подробнее про this.». Начинающие разработчики, как правило, дают очень туманные ответы: "this – это объект «перед точкой», который использовался для вызова метода", "this — контекст, в котором был вызвана функция" и т.д.…

На самом деле, ситуация с этим центральным для EcmaScript языков понятием обстоит несколько сложнее. Разберёмся по порядку.

Допустим, у нас есть программа на языке JavaScript, в которой есть переменные объявленные глобально; глобальные функции; локальные функции(объявленные внутри других функций), функции, возвращаемые из функций.

Всем, кому приходилось вставлять HTML содержимое в DOM в Angular, доводилось видеть это сообщение. Конечно, все мы получаем проверенное содержимое с нашего же сервера и просто хотим застилизовать сообщение об ошибке. Или вставляем HTML из наших же констант, инлайним наши SVG иконки, ведь нам всего лишь нужно покрасить их в цвет текста. Ведь ничего плохого не случится, если мы просто скажем Angular`у — не дрейфь, там всё чисто.

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

Это и последующие руководства проведут вас через процесс создания решения на основе проекта Discovery.js. Наша цель — создать инспектор NPM-зависимостей, то есть интерфейс для исследования структуры node_modules.

Примечание: Discovery.js находится на ранней стадии разработки, поэтому со временем что-то будет упрощаться и становиться полезнее. Если у вас есть идеи, как можно что-то улучшить, напишите нам.

Аннотация

Ниже вы найдёте обзор ключевых концепций Discovery.js. Изучить весь код руководства можно в репозитории на GitHub, или можете попробовать как это работает онлайн.