Предлагаю вашему вниманию перевод статьи "Neon: Node + Rust".

Javascript программистам, которых заинтриговала rust-овская тема бесстрашного программирования (сделать системное [низкоуровневое] программирование безопасным и прикольным), но при этом ждущих вдохновений или волшебных пендалей — их есть у меня! Я тут поработал немного над Neon — набором API и тулзов, которые делают реально легким процесс написания нативных расширений под Node на Rust.

TL;DR:

• Neon — это API для создания быстрых, надежных нативных расширений Node на Rust
• Neon позволяет использовать параллелизм Rust-а с гарантированной потокобезопасностью
• Neon-cli позволяет легко и непринужденно создавать Neon проект и дает легкий старт… и наконец...
• проекту требуется помощь!

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

Это последняя статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Осторожно, под катом 7 МБ картинок.

Так уж вышло, что род моей деятельности тесно переплетен с созданием ботов для Telegram. Писать я их начал сразу после появления Telegram Bot API, тогда никаких инструментов для этого не было. Пришлось самому писать библиотеку для работы с API, о чем я частично уже рассказывал в своей предыдущей статье. С течением времени библиотека несколько раз была переписана и в итоге обросла разными фишками. В статье я постараюсь рассказать о том, как с ее помощью писать ботов.

Предлагаем вашем вниманию перевод статьи "Running JavaScript in Azure DocumentDB with Chakra" от Andrew Liu (Program Manager, Azure DocumentDB) и Limin Zhu (Program Manager, Chakra).

Chakra — это JavaScript-движок, используемый в Microsoft Edge и универсальных Windows-приложениях. Начиная с Windows 8.1 и Windows Server 2012 R2, в Chakra появился новый набор API для встраивания (JavaScript Runtime, или JSRT API), позволяющий применять Chakra за рамками упомянутых клиентских сценариев.



Azure DocumentDB стал одним из первых сервисов со встроенной Chakra, используемой для нативной реализации скриптовых возможностей в движке баз данных. С недавним анонсом открытия ключевых компонетов Chakra (ChakraCore) на GitHub мы также рады поделиться нашим опытом и планами на будущее использование Chakra.

Разрабатывая игру, приходится идти на всевозможные ухищрения для повышения производительности. В самом деле, если сцена будет притормаживать при каждом выстреле или генерации врагов, то пользователь может махнуть рукой и найти более шуструю игру (благо рынок ими сейчас перегружен). «Узких мест» в игровом приложении немало, но я хотел бы рассказать про оптимизацию именно со стороны кода.

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

В этом посте изложены советы, как не написать код, производительность которого окажется гораздо ниже ожидаемой. Особенно это касается ситуаций, когда движок V8 (используемый в Node.js, Opera, Chromium и т. д.) отказывается оптимизировать какие-то функции.

Друзья мои! Время от времени каждый из нас сталкивается с ситуацией, когда, попав на новый для себя сайт, приходится хорошенько поразмыслить минуту-другую, чтобы понять, как там все устроено. Примерно в таком же положении можно оказаться, обнаружив радикальные (или не очень) перемены во внешнем облике любимых сайтов, будь то last.fm или Кинопоиск. Существуют разные способы примирить пользователей с новым дизайном: от постепенного знакомства с привнесенными новшествами («Попробуйте бета-версию обновленного сайта прямо сейчас!») до создания пошагового гайда по новым возможностям. О последнем варианте мы сегодня и поговорим.

Моя серия заметок ES6 in Depth, состоящая из 24 записей, описывает большинство синтаксических изменений и нововведений в ES6. В этой публикации я подведу итог всего изложенного в предыдущих статьях, чтобы дать возможность посмотреть еще раз на всё вместе. Также я добавил ссылки на мой блог, чтобы в случае необходимости сразу же можно было посмотреть подробнее.



Я слышал, вы любите маркированные списки, так что вот вам статья со списком, который состоит из нескольких сотен элементов.

Часть 1: Реализуем WebSocket. Введение.

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

В первой части мы рассмотрим начальную настройку окружения и реализацию простейшего WebSocket-сервера. Чтобы понять технические детали статьи вам не потребуется опыта работы с языком Rust, хотя знание основ системных API (POSIX) и C/C++ лишним не будет. Прежде чем начинать чтение, заготовьте немного времени (и кофе) — статья описывает все максимально подробно и поэтому довольно длинная.

Нам в Хекслете нравится ReactJS и Flux. Нам кажется, что это правильное направления развития. Мы любим функциональное программирование и чистые функции, и когда сложные архитектуры упрощаются за счет подходов, связанных с ними — это круто. По Реакту уже есть немало ресурсов в интернете, в том числе наш практический курс по React JS. Последний урок в этом курсе называется «Однонаправленное распространение данных», и там мы подходим к интересной теме, которая лежит в основе архитектуры Flux.

Flux это паттерн распространения даных в приложении. Flux и React выросли в стенах Фейсбука вместе. Многие используют их одновременно, но ничто не мешает использовать их по отдельности. Они были созданы для решения конкретной проблемы в Фейсбуке.

Мы используем React и Flux в своей браузерной среде разработки Hexlet IDE (она в опен-сорсе), в которой учащиеся выполняют практические задания. Flux одновременно очень популярен и очень непонятен для многих в мире веба. Сегодняшний перевод — попытка объяснить Flux на пальцах (ну, то есть картинках).

Проблема

Вначале нужно понять, какую проблему решает Flux.

Предшествующая статья про исключения в С++ оставила кучу тёмных мест,
главное, что осталось непонятным — так как же всё-таки осуществляется
передача управления при возбуждении исключения?
С SJLJ всё понятно, но, утверждается, что эта технология практически
вытеснена некоторым без-затратным (при отсутствии исключений) табличным механизмом.
А вот что это за механизм такой и как он устроен, будем разбираться под катом.

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

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

Важные замечания:

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

Также зацените эту инфографику (вариант на русском), если вы просто начинающий программист.

Несколько дней назад мы с TheShock создали топик в котором собирали ваши вопросы, касательно JavaScript (архитектура, фрэймворки, проблемы). Настало время ответить на них. Мы получили очень много вопросов, как в комментариях так и по email. Эта первая часть ответов — те вопросы, которые достались мне.

Уже около полугода я пишу на ES6 (который в итоге назвали ES-2015) и ES7, с использованием бабеля в качестве транслятора. Писать мне приходилось в основном серверную часть, соответственно, использование модулей было само собой разумеющимся: до ES6 — с помощью модульной системы самой ноды, а теперь — с помощью стандартизированной семантики самого языка. И мне захотелось написать статью, в которой расписать тонкости, плюсы, подводные камни и необычности новообретенной модульной системы языка: отчасти — чтобы другим было проще, отчасти — чтобы разобраться во всём окончательно самому.

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

Эта статья представляет из себя рассказ о том как устроены исполняемые файлы (в точку! Это именно те штуки, которые получаются после компиляции приложений с расширением .exe). После того, как написан код, подключены библиотеки, подгружены к проекту ресурсы (иконки для окон, какие-либо текстовые файлы, картинки и прочее) всё это компонуется в один единственный исполняемый файл, преимущественно с расширением .exe. Вот именно в этот омут мы и погрузимся.
*Статья находится под эгидой «для начинающих» поэтому будет изобиловать схемами и описанием важных элементов загрузки.

Ряд публикаций Джейсона Орендорфа ES6 In Depth посвящен ES6, который добавили в язык программирования JavaScript в 6 итерации ECMAScript.

Сегодня будем делать такие штуки:



Немного сложно для первого примера. Подробнее объясню позже, пока что посмотрим, что за объект мы создали.

Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Прогрессбар — элемент вроде и редко встречающийся на сайтах (в отличии от селектов, чекбоксов, инпутов и прочего), но все равно без него не обойдется ни один ui-kit.

На данный момент HTML5 предоставляет нам нативный элемент progress, базовый функционал которого поддерживается практически всеми современными браузерами (caniuse.com/#feat=progress).

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

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

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

В целом, статей и туториалов про использование замыканий в JS полно, но объяснений как это все работает внутри — мало. Сегодняшний перевод посвящен именно этой теме. Как и почему работают замыкания в JS, когда они создаются и уничтожаются и почему каждая функция в JS — это замыкание.

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?