В этой статье я расскажу о результате своей второй попытки борьбы с колбеками в JavaScript. Первая попытка была описана в предыдущей статье. В комментариях к ней мне подсказали некоторые идеи, которые были реализованы в новом проекте — nsynjs (next synjs).
TLDR: nsynjs — это JavaScript-движок, который умеет дожидаться исполнения колбеков и исполнять инструкции последовательно.
Читать полностью »
Обмен сообщениями достаточно фундаментальная вещь в науке Computer Science. Будем рассматривать её в приближении к событийно-ориентированному программированию (event-driven). Терминология, возможности и реализации могут отличаться: события (events), сообщения (messages), сигналы/слоты (signals/slots) и callbacks. В целом суть, что с приходом события запускается ответная реакция.
Сама система обмена сообщениями в статье послужила демонстрацией вольной, но допустимой интерпретации ссылок/указателей, упрощающей код. Получившаяся система тривиальна и умеет только регистрировать обработчик на определённый код сообщения и посылать сообщения с таким кодом.
Допустим что обработчики нетривиальные, а сообщений немного. И что мы сами генерируем сообщения и они не приходят нам по сети, например. В таком случае хочется иметь что-то более удобное с явными объявлениями переменных в сообщении. Например, нечто подобное:
StringMessage* str_message = ...;
send(my_message);
...
void handle_message(const Message* message) {
assert(message);
const StringMessage* str_message = dynamic_cast<const StringMessage*>(message);
assert(str_message);
std::cout << str_message->message ...
}
Но хочется убрать проверочный код, не имеющий отношения к логике работы, под капот. Заменим поэтому указатель на ссылку, показав что в обработчик точно приходит объект, а не NULL nullptr. И пусть обработчик сразу принимает требуемый им тип сообщения.
void handle_message(const StringMessage& message) {
...
}
Как осуществить задуманное и поддержать другие возможные классы сообщений?
Читать полностью »
Я постоянно слышу людей, ноющих об асинхронных коллбэках в JavaScript. Держать в голове порядок исполнения в этом языке немного трудно (это тот случай, который называют «Callback Hell» или «The Pyramid of Doom»), если до этого ты имел дело с синхронным программированием. Моим обычным ответом было «тебе придется как-то с этим обходиться». В конце концов, ожидаем ли мы, что все языки программирования будут выглядеть и ощущаться одинаково? Конечно нет.
Все поменял недавний обзор черновика ECMAScript 6, в котором описываются генераторы — возможность языка, которая целиком изменит наш способ написания и серверного, и клиентского JavaScript. С помощью генераторов мы можем превратить вложенные коллбэки в похожий на синхронный код без блокирования нашей единственной event loop.
Например, этот код:
setTimeout(function(){
_get("/something.ajax?greeting", function(err, greeting) {
if (err) { console.log(err); throw err; }
_get("/else.ajax?who&greeting="+greeting, function(err, who) {
if (err) { console.log(err); throw err; }
console.log(greeting+" "+who);
});
});
}, 1000);
может быть написан так:
sync(function* (resume) {
try (e) {
yield setTimeout(resume, 1000);
var greeting = yield _get('/something.ajax?greeting', resume)
var who = yield _get('/else.ajax?who&greeting=' + greeting, resume)
console.log(greeting + ' ' + who)
}
catch (e) {
console.log(e);
throw e;
}
});
Интересно, не правда ли? Централизованная обработка исключений и понятный порядок исполнения.
Читать полностью »
В последние годы требования к приложениям значительно изменились. Десятки серверов, время отклика в несколько секунд, оффлайновое обслуживание, которое могло длиться часами, гигабайты данных — такими были большие приложения буквально несколько лет назад. Сегодня же приложения работают абсолютно на всём, начиная с простых мобильников и заканчивая кластерами из тысячи процессоров. Пользователи ожидают миллисекундного времени отклика и стопроцентного аптайма, в то время как данные выросли до петабайтов.
Первоначально эту нишу занимали крупные инновационные интернет-компании типа Google или Twitter, однако такие требования к приложениям начали всплывать во многих областях индустрии. Финансовые и телекоммуникационные компании первыми начали внедрять новые практики, чтобы удовлетворить новым требованиям, а теперь подтягиваются и остальные.
Новые требования требуют новых технологий. Предыдущие решения делали упор на управляемые сервера и контейнеры. Масштабирование достигалось засчёт покупки более крутых серверов и использования многопоточности. Для добавления новых серверов приходилось применять комплексные, неэффективные и дорогие проприетарные решения.
Однако прогресс не стоит на месте. Архитектура приложений эволюционировала в соответствии с изменившимися требованиями. Приложения, разработанные на основе этой архитектуры, мы называем Реактивными Приложениями. Такая архитектура позволяет программистам создавать событийно-ориентированные, масштабируемые, отказоустойчивые и отзывчивые приложения — приложения, работающие в реальном времени и обеспечивающие хорошее время реакции, основанные на масштабируемом и отказоустойчивом стеке и которые легко развернуть на многоядерных и облачных архитектурах. Эти особенности критически важны для реактивности.
В этой статье на примере реализации механизма обратного вызова будет рассмотрена возможности применения лямбда функций в удобной и быстрой форме.
Читать полностью »
Ruby — очень интересный язык. Одной из его особенностей является возможность выполнения заданных функций при добавлении модуля в класс. Стандартный пример выглядит следующим образом:
module MyModule
module InstanceMethods
end
module ClassMethods
end
def self.included(base)
base.include(InstanceMethods)
base.extend(ClassMethods)
end
end
Здесь создаются два под-модуля в рамках текущего модуля для разделения методов инстанса и методов класса. При «примешивании» модуля MyModule в класс выполняется функция included, которая добавляет необходимые методы класса и методы объектов класса.
Не так давно я открыл для себя еще одну подобную функцию, которая выполняется при наследованииЧитать полностью »