Node.JS *

Для обычного пользователя программы, которые мы пишем — это магия. Фронт, бэк — неважно. Человек нажимает на кнопку в браузере, и вдруг случается чудо. Но мы-то знаем, что это не чудо, а результат упорной работы.

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

Это происходит само собой, просто по статистике? Если набрать достаточное количество докладов, всё получится автомагически? Как бы не так. Всё подстроено. Как программу на JS проектируют архитекторы, так и за каждой конференцией стоит команда отличных инженеров, которые проектируют её специальным образом. Они проектируют не только структуру, но и вместе с докладчиками «отлаживают» каждый доклад, строчка за строчкой, раз за разом. Проводят кросс-ревью, оценку, починку багов. Пишутся специальные инструменты и выкладываются на GitHub. И так до тех пор, пока не скомпилируется хорошо работающая, безбажная конференция.

Наверное, каждый иногда хотел пообщаться с разработчиками тех инструментов, которыми мы все пользуемся. К примеру, кто хотел бы сказать пару ласковых создателям React или Node.js? А кто хотел бы узнать от них парочку тайн о внутренней кухне проекта?

Это интервью — с разработчиками конференции HolyJS 2017 Moscow, с её Программным комитетом. Мы будем обсуждать:

• какие сложности возникают при разработке программы конференции и как их побеждают;
• кто допущен к сакральному процессу отбора докладов и нужно ли для этого быть богом JavaScript;
• совместима ли работа в ПК с обычной жизнью;
• какие доклады стоит послушать и на какие ни в коем случае не стоит приходить хипстерам;
• кучу рандомных интересных фактов.

Недавно в компании Reside Real Estate столкнулись с проблемами: в самые ответственные моменты начал падать Node.js-сервер. Подозрение пало на память. Сотрудники компании прибегли к временным мерам, что позволило избавить от неудобств пользователей, и занялись поисками источника проблем. В результате им удалось найти и устранить неполадки.

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

Продолжая начатую тему хочется поделиться успешным опытом создания билингвистического Node.JS бота на Microsoft Bot Framework под Linux. От заказчика поступила задача разработать простой социальный бот в формате вопрос-ответ для большой торговой сети, однако сложность заключалась в другом — бот должен быть двуязычным: на английском и арабском. Хотя, как будет показано ниже, выбор инструментов для решения задачи сделал разработку лёгкой, приятной и интересной.

Эту статью написал программист из Италии Валентино Гаглиарди. Он говорит, что сразу после выхода Puppeteer его заинтересовала автоматизация тестирования веб-интерфейсов с использованием данной библиотеки и Jest. После этого он приступил к экспериментам.



Здесь речь пойдёт об основах работы с Puppeteer и Jest на примере тестирования веб-формы. Также тут будут рассмотрены особенности использования Chromium с пользовательским интерфейсом и без него, и некоторые полезные мелочи, касающиеся различных аспектов тестирования веб-страниц и организации рабочей среды. Валентино полагает, что, хотя Puppeteer — инструмент сравнительно новый и его API вполне может подвергаться изменениям, у него есть шанс занять достойное место в арсенале веб-разработчиков.

Всем ведь давно надоели колбэки в асинхронных вызовах и спагетти код? К счастью, в es6 появился новый сахар async/await для использования любых асинхронных функций без головной боли.

Представим себе типовую задачу. Клиент положил товары в корзину, нажал «Оплатить». Корзина должна улететь в ноду, создается новый заказ, клиенту возвращается ссылка на оплату в платежную систему.

Перед вами четвёртая часть серии материалов, которые посвящены разработке веб-приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой, второй и третьей частях речь шла о создании основных серверных и клиентских компонентов приложения. Сегодня мы продолжим развитие проекта, а именно — займёмся списками документов и клиентов. Кроме того, нельзя не заметить, что к настоящему моменту сделано уже немало, поэтому вполне можно критически взглянуть на то, что получилось, и поработать над повторным использованием кода.

Seneca — microservices toolkit для Node.JS. Он предоставляет плагины, которые заботятся об основах вашего приложения. Это позволяет сосредоточиться на реальной бизнес-логике. Нет необходимости беспокоиться о том, какую базу данных использовать, как структурировать компоненты или как управлять зависимостями. Просто начните писать код.

Вы описываете всё как действия. Действия вызываются всякий раз, когда они соответствуют набору свойств. Ваш вызывающий код не знает и не заботится, какое действие выполняет работу. Один объект JavaScript входит, а другой выходит, асинхронно.

Чем Seneca.js не является

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

• Seneca — это не “строгий” фреймворк. Seneca не навязывает вам ни архитектуру приложения ни каких-либо подходов. Хотите разместить все свое приложение в одном действии? Вы можете. Хотите сделать каждое действие всего в 5 строк кода? Вы тоже можете это сделать. Seneca невероятно надежен и будет работать практически со всеми архитектурными решениями, которые вы принимаете.

Сегодня публикуем третью часть из серии материалов, посвящённой разработке приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой и второй частях мы создавали сервер, настраивали механизмы аутентификации и занимались обустройством фронтенда. В этом материале продолжим работать над клиентской и серверной частями системы. То, что уже создано, пока почти не касается логики самого приложения, которое предназначено для работы с финансовыми документами. Поэтому, кроме прочего, мы займёмся и этим аспектом проекта.

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

Что у нас получилось — можно посмотреть здесь.

В этом году, на конференции Forward.js, посвящённой JavaScript, я выступал с докладом «You don’t know Node». Во время выступления я задал аудитории несколько вопросов о Node, и большинство присутствующих не смогли ответить на многие из них. А ведь мой доклад слушали технические специалисты. Никаких подсчётов я не производил, но выглядело всё именно так, да и несколько слушателей, которые подошли ко мне после выступления, это подтвердили.

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

Библиотека puppeteer для Node.js позволяет автоматизировать работу с браузером Google Chrome. В частности, с помощью puppeteer можно создавать программы для автоматического сбора данных с веб-сайтов, так называемые веб-скраперы, имитирующие действия обычного пользователя. В подобных сценариях может применяться браузер без пользовательского интерфейса, так называемый «Headless Chrome». Используя puppeteer, можно управлять и браузером, который запущен в обычном режиме, что особенно полезно при отладке программ.

Сегодня мы поговорим о создании веб-скрапера на базе Node.js и puppeteer. Автор материала стремился к тому, чтобы статья была интересна как можно более широкой аудитории программистов, поэтому пользу из него извлекут как те веб-разработчики, которые уже имеют некоторый опыт работы с puppeteer, так и те, которые впервые сталкиваются с таким понятием, как «Headless Chrome».

Недавно я познакомился с методом тестирования ПО под названием «Мутационное тестирование» и уже успел стать фанатом такого подхода к написанию тестов.

Сначала теория

Цель мутационного тестирования состоит в выявлении неэффективных и неполных тестов, то есть это по сути тестирование тестов.

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

Если вы не изучали JavaScript с самого начала, то осваивать его современную версию сложно. Экосистема быстро растёт и меняется, так что трудно разобраться с проблемами, для решения которых придуманы разные инструменты. Я начал программировать в 1998-м, но начал понимать JavaScript только в 2014-м. Помню, как просматривал Browserify и смотрел на его слоган:

Browserify позволяет делать require («модули») в браузере, объединяя все ваши зависимости

Я не понял ни слова из предложения и стал разбираться, как это может помочь мне как разработчику.

Цель статьи — рассказать о контексте, в котором инструменты в JavaScript развивались вплоть до 2017-го. Начнём с самого начала и будем делать сайт, как это делали бы динозавры — безо всяких инструментов, на чистом HTML и JavaScript. Постепенно станем вводить разные инструменты, поочерёдно рассматривая решаемые ими проблемы. Благодаря историческому контексту вы сможете адаптироваться к постоянно меняющемуся ландшафту JavaScript и понять его.

Если в первый момент идея не кажется абсурдной, она безнадёжна.
— Альберт Эйнштейн

Мы собрали для вас самые популярные темы из обсуждений Node.js на Хабре, и попросили рассказать о них признанных экспертов: некоммерческого Node-хакера Матиаса Мэдсена и автора множества книг и курсов по Node, Азата Мардана.

Вот точный список тем:

1. Потоки в Node.js и способы распараллеливания вычислений;
2. Асинхронность в Node.js;
3. Отладка и логирование в Node.js;
4. Проблемы мониторинга производительности на продакшене;

5. Инструменты для мониторинга нод.

   
   

   Азат Мардан (Azat Mardan) — Tech Fellow, менеджер в компании Capital One, и эксперт по JavaScript/Node.js с несколькими онлайн-курсами на Udemy и в Node University, а также автор 14 книг по той же тематике, включая «React Quickly» (Manning, 2017), «Full Stack JavaScript» (Apress, 2015), «Practical Node.js» (Apress, 2014) и «Pro Express.js» (Apress, 2014).

   
   

Firebase отличный инструмент для быстрой разработки приложений. Однако при использовании Firebase и Angular Universal могут возникнуть следущие вопросы:

• Какой пакет firebase использовать в браузере пользователя и какой использовать на сервере?
• Какой механизм использовать для асинхронных операций?
• Как передать данные с сервера браузеру, избегая дублирования запросов?

Перед вами — вторая часть серии материалов, которая посвящена созданию веб-приложения Budget Manager с использованием Node.js, Vue.js и MongoDB. В первой части мы занимались сервером, а именно — подготовили основные методы RESTful API и наладили JWT-аутентификацию. Сегодня приступим к работе над клиентской частью приложения, создадим каркас фронтенда, средства для регистрации в системе и входа в неё, поговорим о маршрутах и об их защите.

Поработав с Angular Material 2, в какой то момент пришел к выводу, что продукт сыроват для полета фантазии и некоторые вещи (badge, vertical tabs, data-grid) либо реализованы с минимальным функционалом, либо In progress, planned.

Вечером, придя домой, начал искать что нибудь, что мог бы предложить тимлиду как альтернативу для следующего проекта. Тут то я и заметил, что angular.io разжился табом Resources. Это было пару месяцев назад.
Там среди прочих довольно таки полезных вещей, команда разработчиков Angular, добавила продукт от не менее известной компании, чьи разработки я уважаю и с щенячьим восторгом всегда рад лишний раз поковырять — VmWare. Ребята сделали весьма и весьма достойный продукт — Clarity.

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

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

Мы уже писали на Хабре о докладах в основных потоках FrontFest — JavaScript, вёрстка, смежные и экспериментальные технологии. Настало время рассказать о форматах. Помимо докладов будут квартирники (такой вид дискуссионных панелей) и воркшопы. Сегодня поговорим о воркшопах, и сразу главное — посещение воркшопов не требует никаких доплат и доступно по обычному билету участника. Да, вот так просто.

На воркшопах вы узнаете о хакерских способах низкоуровневых оптимизаций, приобретете навыки работы с Web Audio API и 3D на Canvas, научитесь делать свои веб-приложения нативными для iOS, Android, Windows и MacOS с помощью Ionic (Angular) и построите production-ready бекенд на Node.js с нуля.

Перед вами — первый материал из серии, посвящённой разработке полноценного веб-приложения, которое называется Budget Manager. Основные программные средства, которые будут использованы в ходе работы над ним — это Node.js для сервера, Vue.js для фронтенда, и MongoDB в роли базы данных.



Эти материалы рассчитаны на читателей, которые знакомы с JavaScript, имеют общее представление о Node.js, npm и MongoDB, и хотят изучить связку Node-Vue-MongoDB и сопутствующие технологии. Приложение будем писать с нуля, поэтому запаситесь любимым редактором кода. Для того, чтобы не усложнять проект, мы не будем пользоваться Vuex и постараемся сосредоточиться на самом главном, не отвлекаясь на второстепенные вещи.

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