Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 9787 сообщений
Cообщения с меткой

javascript - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Приложение для запоминания иностранных слов

Вторник, 28 Июня 2016 г. 20:13 (ссылка)

На данный момент создано множество приложений для запоминания слов.

Из тех что мне запомнились могу выделить такие Android приложения как Lingualeo, Английские слова, СловоУч.

Главным недостатком этих приложений для меня был платный аккаунт для добавления своей базы слов.

Поэтому встал вопрос о написании своего приложения для запоминания слов.

Главной идеей было подключения внешнего API словаря и переводчика для переводов слов на родной язык.

В качестве такого API было выбрано Yandex API (API Переводчика и API Словаря).



Первым делом необходимо было получить ключи разработчика.

Для переводчика https://tech.yandex.ru/keys/get/?service=trnsl

и для словаря https://tech.yandex.ru/keys/get/?service=dict



В качестве языка и платформы разработки был выбран JavaScript и библиотека JQuery.



Для получения перевода слова на нужный язык я использовал следующий код:



            var oneWord = function() {
$.post("https://dictionary.yandex.net/api/v1/dicservice.json/lookup",
{
key: apiKey,
lang: lang,
text: words[index].text
}, function(data)
{
words[index].tr = "";
words[index].ts = "";
for (var j = 0; j < data.def.length; j++) {
var def = data.def[j];
for (var k = 0; k < def.tr.length; k++) {
var tr = def.tr[k];
words[index].tr += tr.text + "; ";
}
if (def.ts)
words[index].ts = def.ts;
}
if (words[index].tr == "") {
translateWords();
tsWords();
return;
} else {
var str = words[index].tr;
words[index].tr = str.substring(0, str.length - 2);
}
complete();
},
"json");
};
var tsWords = function() {
var text = words[index].text;
var tsText = "";
var tsWords = text.match(/\S+/gi);
var tsIndex = 0;
var tsPost = function() {
$.post("https://dictionary.yandex.net/api/v1/dicservice.json/lookup",
{
key: apiKey,
lang: lang,
text: tsWords[tsIndex]
}, function(data)
{
var ts = "";
for (var j = 0; j < data.def.length; j++) {
var def = data.def[j];
if (def.ts)
ts = def.ts;
}
tsText += ts + " ";
if ((tsIndex < (tsWords.length - 1)) && (tsIndex < 5)) {
tsIndex++;
tsPost();
} else {
words[index].ts = tsText.trim();
complete(false, true);
}
},
"json");
};
tsPost();
};
var translateWords = function() {
$.post("https://translate.yandex.net/api/v1.5/tr.json/translate",
{
key: apiKeyTranslate,
lang: slang,
text: words[index].text
}, function(data)
{
words[index].tr = "";
for (var j = 0; j < data.text.length; j++) {
var text = data.text[j];
words[index].tr += text + "; ";
}
var str = words[index].tr;
words[index].tr = str.substring(0, str.length - 2);
complete(true, false);
},
"json");
};
var qu = function() {
if (!words[index].tr) {
oneWord();
} else {
complete();
}
};
qu();




Тут функция oneWord переводит одно слово, tsWords находит транскрипции первых пяти слов в выражении (если дано не слово, а предложение),

translateWords переводит предложение.



Результирующая функция complete вызывается для заполнения формы слова с транскрипцией и переводом:

        var complete = function(tr, ts) {
if (ts == undefined) ts = true;
if (tr == undefined) tr = true;
var word = words[index];
if (tr) $("#text").html(word.text);
if (ts) $("#ts").html("[" + word.ts + "]");
$("#tr").hide();
$("#attempt").hide();
$("#show").show();
$("#tr").html(word.tr);
$("#tts").show();
};




В массиве слов words index отражает текущее слова для запоминания.

Следующее слово выбирается по следующему алгоритму:

        var words = [],
patternCount = 5,
indexMemory = {},
indexMemoryCount = 0,
patternIndex = [],
lastIndex = -1,
lastIndexs = [],
lastIndexsCount = 2,
wasAttempt = false,
wasMemory = false,
deep = 0,
deepMax = 100;

var index = nextIndex();

var nextIndex = function() {
deep++;
if (lastIndexsCount - words.length >= 0) {
lastIndexsCount = 0;
}
if ((patternIndex.length < patternCount) && (indexMemoryCount < words.length)) {
if (deep > deepMax) {

var index = maxAttemptsIndex(true);
return index;
}
var index = Math.floor(Math.random() * words.length);
if (indexMemory[index]) {
return nextIndex();
}
indexMemory[index] = "do";
indexMemoryCount++;
patternIndex.push(index);
lastIndex = index;
pushIndex(lastIndex);
return index;
} else {
var index = Math.floor(Math.random() * (patternIndex.length + 1));
if (index == patternIndex.length || (patternIndex.length == 0)) {
wasMemory = true;
var ind = maxAttemptsIndex();
if (inArray(lastIndexs, ind))
{
if (deep > deepMax) {
ind = Math.floor(Math.random() * words.length);
lastIndex = ind;
pushIndex(lastIndex);
return ind;
}
return nextIndex();
}
lastIndex = ind;
pushIndex(lastIndex);
return ind;
}
if (inArray(lastIndexs, patternIndex[index])) return nextIndex();
lastIndex = patternIndex[index];
pushIndex(lastIndex);
return patternIndex[index];
}
};

var maxAttemptsIndex = function(notAttempts) {
var arr = sortMemoryIndexes(indexMemory);
var index = getRandomFishIndex(arr, notAttempts);
return index;
};

var pushIndex = function(index) {
if (lastIndexsCount == 0) return;
if (lastIndexs.length < lastIndexsCount) {
lastIndexs.push(index);
} else {
lastIndexs[0] = lastIndexs[1];
lastIndexs[1] = index;
}
};

var inArray = function(arr, elem) {
for (var i = 0; i < arr.length; i++) {
if (arr[i] == elem)
return true;
}
return false;
};

function getRandomFishIndex(arr, notAttempts) {
var fishForLevel = arr;
var fishTotalWeight = 0, fishCumWeight = 0, i;
// sum up the weights
for (i = 0; i < fishForLevel.length; i++) {
fishTotalWeight += fishForLevel[i].attempts;
}
if (notAttempts) {
fishTotalWeight = 0;
}
var random = Math.floor(Math.random() * fishTotalWeight);
// now find which bucket out random value is in
if (fishTotalWeight == 0) return fishForLevel[Math.floor(Math.random() * fishForLevel.length)].index;
for (i = 0; i < fishForLevel.length; i++) {
fishCumWeight += fishForLevel[i].attempts;
if (random <= fishCumWeight) {
return fishForLevel[i].index;
}
}
}

function sortMemoryIndexes(indexMemory) {
var arr = [];
for (var key in indexMemory) {
if (indexMemory[key] == "do") {
var word = jQuery.extend(true, {}, words[key]);
word.index = key;
arr.push(word);
}
}
var sAttempt = function(first, second) {
if (first.attempts < second.attempts)
return 1;
else if (first.attempts > second.attempts)
return -1;
else
return 0;
};
return arr.sort(sAttempt);
}




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

При этом вероятность показа последних должна быть больше, если слово плохо запоминается.

Именно кнопка «Неправильно» реализует перестановку вероятностей показа слов.

        $("#attempt").click(function()
{
words[index].attempts++;
wasAttempt = true;
$("#attempt").hide();
});




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



HTML и сопутствующий JavaScript код был обернут в Cordova для платформы Android.



Приложение «EnglishWords» позволяет учить английские слова и слова многих других языков. В программе имеется базовый набор слов для изучения. Главной особенностью программы является возможность создавать свои наборы слов для изучения. ИНФОРМАЦИЯ НА ЭКРАНЕ * Процент. Означает процент изученных слов в словаре. КАК ЭТО РАБОТАЕТ. Процесс изучения слов начинается с того, что программа набирает из выбранных словарей 5 случайных слов и начинает их показывать в случайном порядке. После того, как слова выучены из словаря извлекаются следующие 5 случайных слов. Если вы отвечаете не правильно на слово, то слово будет показываться чаще. Когда все слова выучены показываются только те слова на которые чаще всего давался не правильный ответ. СЛОВАРЬ Базовый набор слов содержит около 1000 наиболее употребляемых

английских слов.

Приложение использует yandex и google api для получения перевода, транскрипции и звукового воспроизведения. Для работы приложения необходим доступ в интернет.



Приведу скриншоты приложения:





Приложение доступно в Play Маркете по адресу:

https://play.google.com/store/apps/details?id=svlab.englishwords



Также доступна web версия приложения по адресу:

https://svlaboratory.org/application/english-words
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304334/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Визуализация с Google Chart Tools API

Вторник, 28 Июня 2016 г. 13:24 (ссылка)

Google Chart Tools API – это многофункциональный набор инструментов для визуализации данных. С помощью него можно относительно легко строить графики и диаграммы на сайте.



Функционал Google Chart Tools API включает в себя:




  • Динамические пиктограммы;

  • Карты;

  • Циферблаты и дисплеи;

  • Формулы;

  • QR-коды;

  • Возможность создавать свои инструменты визуализации и использовать сторонние.



Карта



image

Сделаем визуализацию данных с помощью карты, раскрашенной в соответствии с внесенными данными. Для начала подключаем файлы, loader.js обязателен.




/* Дополнительно для карты. */


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



google.charts.load('current', {'packages':['geochart']});
google.charts.setOnLoadCallback(drawChart);


Вместо geochart можно поместить:



Orgchart – Дерево.

Map – Карта

Annotationchart – График.

Corechart – Диаграмма.

Gauge – Спидометр.

И многое другое.



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



var data = google.visualization.arrayToDataTable([
['Country', 'Popularity'],
['Sweden', 300],
['United States', 300],
['France', 400],
['Canada', 500],
['Spain', 500],
['RU', 900]
]);


Дополнительные настройки.



var options = {
title: 'Simple map' // Заголовок.
};


Указываем контейнер, в который будем помещать карту.



var chart = new google.visualization.GeoChart(document.getElementById('regions_div'));
chart.draw(data, options);
}


Контейнер.






По такому шаболну строятся все эффекты визуализации GCT API.



Диаграмма



image

Теперь создадим простую диаграмму.



google.charts.load('current', {'packages':['corechart']});
google.charts.setOnLoadCallback(drawChart);
function drawChart() {
var data = google.visualization.arrayToDataTable([
['Color', 'Quantity'],
['Orange', 11],
['Black', 2],
['Red', 1],
['White', 2],
['Green', 7]
]);


Чтобы сделать диаграмму 3D, добавляем параметр is3D:true.



var options = {
title: 'Quantity of colors',
is3D: true
}


Можно «вырезать» центр.



pieHole: 0.4


Или «вытащить» кусочки диаграммы на расстояние.



slices: {  4: {offset: 0.2},
1: {offset: 0.3},
2: {offset: 0.4},
3: {offset: 0.5},
}


Ступенчатая диаграмма создается аналогичным образом, но в настройки нужно добавить isStacked: true.



Дерево



image

Теперь создадим «дерево», где слова визуально соединяются между собой.



Попробовать.



Подключаем элемент wordtree.



google.charts.load('current', {packages:['wordtree']});
google.charts.setOnLoadCallback(drawChart);


В настройках выводим слово, от которого будет строиться дерево. Строка format имеет большое значение: если указать implicit, то дерево будет строиться автоматически от указанного слова. Значение explicit позволяет строить дерево в ручном режиме.



 var options = {
wordtree: {
format: 'implicit',
word: 'коты',
colors: ['red', 'black', 'green'] // Зададим цвета.
}
};


От слова «коты» будет строиться дерево, одинаковые слова будут объединяться в одно.



 function drawChart() {
var data = google.visualization.arrayToDataTable(
[ ['Phrases'],
['коты едят меньше собак'],
['коты едят мышей'],
['коты едят мышей и хомячков'],
['коты превосходны'],
['коты меньше собак']
]
);


Датчик



image

И, в завершение, хочется показать работу датчиков – спидометров.



Попробовать.



Подключение.



google.charts.load('current', {'packages':['gauge']});


В массиве указываем название датчика и позицию стрелки.



var data = google.visualization.arrayToDataTable([
['Label', 'Value'],
['Gas', 80],
['Oil', 55],
['Аmperage', 68]
]);


В опциях указаны:



Размер блока с датчиками, разрисовка полей датчика красным и желтым цветом.

Позиция minorTicks:5 уменьшает цену деления датчика.



var options = {
width: 400, height: 120,
redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90,
minorTicks: 5
};


Пусть при нажатии на кнопку, датчики обновляются.



JS код
 google.charts.load('current', {'packages':['gauge']});
google.charts.setOnLoadCallback(drawChart);
function drawChart() { // Функция вызывается событием onclick.

var data = google.visualization.arrayToDataTable([
['Label', 'Value'],
['Gas', 80],
['Oil', 55],
['Аmperage', 68]
]);

var options = {
width: 400, height: 120,
redFrom: 90, redTo: 100,
yellowFrom:75, yellowTo: 90,
minorTicks: 5
};

var chart = new google.visualization.Gauge(document.getElementById('chart_div'));

chart.draw(data, options);
data.setValue(0, 1, 40 + Math.round(60 * Math.random())); // Выбирается случайное значение для каждого датчика
chart.draw(data, options);
data.setValue(1, 1, 40 + Math.round(60 * Math.random()));
chart.draw(data, options);
data.setValue(2, 1, 60 + Math.round(20 * Math.random()));
chart.draw(data, options);
}




Методы визуализации с помощью GCT API очень разнообразны, весь их функционал не поместится в рамки этого поста, документацию по этой библиотеке можно почитать тут.
Original source: habrahabr.ru.

https://habrahabr.ru/post/304296/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Обзор новорождённой платформы Scorocode

Понедельник, 27 Июня 2016 г. 15:19 (ссылка)





BaaS-платформы (Backend as a Service) сделали разработку и сопровождение backend'а для мобильных и веб-приложений достаточно простыми и предсказуемыми процессами. Одним из флагманов движения BaaS стала компания Parse, но в 2016 году она заявила о прекращении обслуживания клиентов с 2017 года.



В связи с закрытием их сервиса и отсутствием русскоязычных облачных BaaS, мы решили создать собственный аналог — Scorocode. Об этом под катом.



Расцвет BaaS



Разработка серверной части — самый трудный и непредсказуемый этап создания приложения. Зачастую, при планировании разработки проекта, недооценивается необходимый объём ресурсов и время создания backend'а.



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



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



Долгое время ИТ-индустрия искала способы упрощения разработки backend'а. Многие компании создавали инструменты, облегчающие работу над частными аспектами разработки, но это только затрудняло процесс: разработчикам приходилось разбираться не только в конкретной СУБД или платформе, но и в дополнительных инструментах.



Всё изменилось в 2011 году, когда компания Parse предложила новый подход к созданию backend'а на основе облачного сервиса. Он позволял решить две основные задачи:




  • Хранение в облаке и свободное манипулирование структурированными данными;

  • Возможность писать серверную бизнес-логику на JavaScript — стабильно популярном языке программирования на протяжении нескольких лет.



Позднее были добавлены другие полезные функции, облегчающие создание backend'а и инструменты для решения рутинных задач.



Идея имела колоссальный успех. В середине 2012 года сервисом пользовалось 20 000 разработчиков, а ежемесячный прирост пользователей составлял 40%. Теперь этап разработки backend'а занимал дни, а не месяцы, и сэкономленные ресурсы можно было направить на разработку и совершенствование frontend'а.



Использование BaaS позволило точнее оценивать сроки разработки и необходимые ресурсы. Сам процесс создания backend'а стал более формализованным, позволяя для разных платформ использовать единую серверную часть, упростилось сопровождение проекта, расходы снизились и стали более прогнозируемы.



Scorocode: начало



Три года назад Facebook приобрёл Parse, и в конце 2015 года социальная сеть решила использовать мощности BaaS монопольно. Все остальные разработчики должны в течение 2016 года мигрировать на другие ресурсы.



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



Scorocode: техника вопроса



Scorocode — горизонтально масштабируемая система, построенная на принципах кластеризации. Кластеры разделяются по типам: API, СУБД, файлы, статистика. Каждый кластер API, работающий с конечными приложениями, выдерживает нагрузку около 25 тысяч запросов в секунду. С ростом нагрузки количество кластеров наращивается.







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



Основная СУБД в Scorocode — MongoDB, в качестве in-memory database используется Redis, а сервер очередей работает под управлением RabbitMQ. Высокопроизводительный API написан «с нуля» на Go. Язык был выбран нами после серии экспериментов с Node.js и С++. Google в последнее время очень активно развивает Go, писать на нём комфортно, код получается компактным, а производительность на уровне С++. Множественные микросервисы платформы тоже разработаны на Go.



Scorocode позволяет исполнять два варианта серверного кода:




  • JS-скрипты с бизнес-логикой. Они хранятся и выполняются на наших серверах. Причём выполняются асинхронно — по расписанию или с запуском вручную с клиентов, посредством вызовов через API. Выполнением серверных скриптов занимается движок Google V8.

  • Триггеры на JS, то есть обработчики операций с данными. Они выполняются высокоскоростным движком, написанным на Go. В данном случае мы отказались от V8, потому что он достаточно долго стартует, а у каждого обработчика есть всего лишь 500 миллисекунд для выполнения кода.



Чем мы отличаемся от конкурентов?




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

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

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

  • Все серверы и данные находятся на территории РФ. Это позволяет нашим клиентам соблюдать требования законодательства.



Финансовый вопрос



На данный момент у нас действует три тарифных плана:




  • Бесплатный “Free”. Если вы начинающий разработчик, то возможностей тарифного плана может хватить для полноценной работы простого приложения.

  • Базовый “Indie”. По умолчанию предоставляется в 1,5-2 раза больше возможностей, чем на бесплатном тарифном плане. Этого уже достаточно для небольших студий и команд разработчиков. Можно расширять возможности тарифного плана, приобретая в Marketplace дополнительные опции.

  • Корпоративный “Enterprise”. Индивидуальные условия для корпоративных клиентов, отсутствие ограничений, выделенные кластеры, космическая техническая поддержка, и т.д.



С платформой Scorocode можно дополнительно сократить затраты на обслуживание приложений:




  • Всем новым разработчикам мы зачисляем при регистрации на счёт платформы по 3000 рублей. Этого достаточно для оплаты одного месяца тарифного плана Indie.

  • Всем новым студиям разработки и digital-агентствам после подтверждения мы зачисляем на счёт платформы 10 000 рублей. Их можно потратить по своему усмотрению — либо взять Indie на три месяца, либо докупить в Marketplace дополнительные опции.



Развитие



У нас оптимистичные планы по развитию Scorocode на четыре года вперёд. Инвестиции и поддержку нам оказывает группа компаний PROF-IT GROUP, которая в 2015 году вошла в рейтинг самых быстрорастущих IT-компаний по версии Cnews.



Ближайшие планы развития:




  • Интеграция с партнёрскими облачными сервисами для расширения методов обработки данных, хранящихся в Scorocode;

  • Фабрика интеллектуальных чат-ботов;

  • Поддержка полного цикла разработки — от backend до frontend.



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



Приглашаем поделиться в комментариях своими пожеланиями и впечатлениями от использования Scorocode.



Мы будем регулярно вести блог с циклом статей про Scorocode: примеры его использования, наш опыт разработки платформы и особенности разработки приложений в целом. Будем рады видеть вас в подписчиках.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303954/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Дайджест свежих материалов из мира фронтенда за последнюю неделю №217 (20 — 26 июня 2016)

Воскресенье, 26 Июня 2016 г. 22:34 (ссылка)

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

























Веб-разработка
CSS
Javascript
Браузеры
Новости и занимательное


Веб-разработка

CSS





JavaScript





Браузеры





Новости и занимательное





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



Дайджест за прошлую неделю.

Материал подготовили dersmoll и alekskorovin.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304152/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Параллакс в 2D игре. Интересный эффект движения при создании игры на JavaScript (canvas)

Воскресенье, 26 Июня 2016 г. 16:46 (ссылка)

При создании игры наткнулся на интересную идею, как можно реализовать эффект трехмерного движения, при создании, например, платформера. Данная возможность, думаю, подойдет для большинства 2D игр, завязанных на скроллинге игрового мира.

image



Тайминг видео:

00:00 — 02:09 — теория

02:08 — 03:32 — создание и позиционирование объектов

03:32 — 05:16 — управление объектом, движение

05:16 — 07:44 — создание эффекта параллакса (трехмерности)

07:44 — 08:50 — закрепление камеры на объекте



Сам урок:

Смотреть 10 минут








Как обычно, если есть вопросы — пишите в комментарии.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304140/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Делаем крутые Single Page Application на Basis.JS. Часть 1, вступительно-теоретическая

Воскресенье, 26 Июня 2016 г. 15:36 (ссылка)

Всем доброго времени суток!

Данная статья начинает цикл публикаций, посвященных basis.js – фреймворку для создания полноценных Single Page Application.





Про фреймворки



Ядро современных фронтенд–фреймворков практически не ориентировано на работу с данными так как не имеет структур и алгоритмов для обработки коллекций.

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

Минусы таких подходов должны быть очевидны.

При манипуляции с DOM–элементами из контроллера/компонента:

— приходится самостоятельно реализовывать структуры данных и алгоритмы обработки наборов данных

— увеличивается сложность и поддерживаемость кода, так как приходится вручную работать с DOM–элементами и налаживать связи между данными и DOM–элементами

— чаще всего невозможно использовать шаблонизаторы



При использовании шаблонизатора в работе с набором данных:

— ухудшается читаемость шаблона, так как логика частично переносится в шаблон

— эффективно ли в шаблонизаторе реализован механизм обновления частей представлений и реализован ли?

— всё еще отсутствуют механизмы обработки наборов данных



Раньше всё это практически не имело значения, так как за обработку данных и их визуальное представление отвечал backend.

Всё, что нужно было сделать – загрузить страницу по нужному адресу и представление уже сформировано.

Минус такого подхода – отсутствие интерактивности и динамичности в плане обновления данных.

Современное SPA должно быть автономным в плане функционала и обращаться на сервер только тогда, когда необходимо синхронизировать данные (сохранить или получить новые).

Соответственно, всю работу по обработке и визуализации этих данных должен брать на себя фронтенд.

С приходом AJAX и WebSocket, стало гораздо проще следить за обновлением данных и обеспечить интерактивность приложения.

Но AJAX и WebSocket про работу с сетью и они не решают базовой задачи – работы с данными.



Допустим, вы делаете одностраничное приложение – клиент для ВКонтакте.

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

Затем добавляется раздел «музыка». Здесь уже требуется работать с плейлистами (как своими, так и друзей). Тот же поиск.

Добавляется раздел «сообщения». Здесь есть работа с «комнатами» и сообщениями.

Думаю смысл понятен…

Так вот: музыка, друзья, сообщения и так далее – это всё данные, которые надо сортировать, группировать, искать и, наконец, визуализировать. При этом визуальное представление должно своевременно обновляться в режиме реального времени.



Таким образом, в арсенале разработчика должны быть мощные и удобные инструменты для работы, теоретически, с любым количеством данных.



Про шаблонизаторы



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

Как бы мы решали задачи описанного выше SPA?

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

Отлично, задачу вывода мы, казалось бы, решили.

Но вот мы понимаем, что в уже отрисованную коллекцию добавились новые элементы.

Что делать?

Опять же, всё очень просто – просим шаблонизатор перерисовать представление, но уже с новыми данными.

И всё вроде бы хорошо, пока данных не так много.

А теперь представим, что у нас есть коллекция из 100 объектов, которую мы получили от сервера.

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

Что мы делаем? Снова отдаем данные шаблонизатору и он, внимание, перерисовывает все ранее отрисованные данные.

Не очень–то эффективно, не правда ли? Особенно если элементов в коллекции будет больше.

Отмечу, что здесь я говорю про строковые шаблонизаторы, которые на вход получают шаблон и данные, а на выходе выдают строку с HTML–кодом, которую и нужно вставить в DOM.

Но строковые шаблонизаторы они на то и строковые, что понятия не имеют об HTML и DOM. Им всё равно какие данные в какой шаблон вставлять и что потом разработчик будет с этими данными делать.



Про умные шаблонизаторы



В противовес обычным, строковым, шаблонизаторам есть более умные.

Их преимущество в том, что они–то уже «в курсе», что работают с HTML и на выходе отдают не строку с HTML–кодом, а DOM–дерево с подставленными в него данными. При этом, каждый элемент данных, который поступил на вход такого шаблонизатора, становится связанным с соответствующим ему DOM–узлом. Таким образом, при изменении какого–либо элемента коллекции, происходит обновление только того узла, с которым этот элемент связан. Возвращаемся к примеру со списком из 100 элементов. В случае с умным шаблонизатором, он сам определит – содержимое каких элементов коллекции было изменено и обновит только соответствующие узлы, не перерисовывая при этом всё представление.

Такой подход, несомненно, более эффективен, особенно при больших наборах данных.

Но, опять же, даже он не решает главной проблемы – работы с данными.

Да, в подобные шаблонизаторы встроена возможность использовать pipe–фильтры, которые позволяют модифицировать данные перед выводом, но, во–первых: такой подход ухудшает читаемость шаблона; во–вторых: это возможность шаблонизатора, а не фреймворка, который использует шаблонизатор и в более сложных ситуациях не спасет от нагромождения кода, как со стороны шаблона, так и со стороны контроллера/компонента.

Как следствие, возникает фундаментальная проблема, которая уже не раз здесь упоминалась – обработка данных.



Про basis.js



Basis.js – это фреймворк, ядро которого строилось с расчетом на работу с данными.

Отличительной особенностью фреймворка является сама модель построения приложения.

Законченное приложение на basis.js представляет собой иерархию компонентов, между которыми циркулирует поток данных.

При этом, образ потока данных лучше всего отражает суть происходящего, ведь создание приложения на basis.js – это налаживание связей между частями приложения.

Грамотно построенное приложение избавляет от необходимости даже банального перебора DOM–элементов.

За всё отвечает сам фреймворк и его гибкие инструменты.

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



Основы работы с basis.js вы можете почерпнуть в этой статье, написанной автором фреймворка.

Мне выпала возможность продолжить цикл статей.



От теории – к практике



Одной из главных составляющих любого SPA является реакция приложения на действия пользователя, другими словами – своевременное обновление данных.

Если мы говорим про данные, то в basis.js есть множество абстракций для описания данных.

Наиболее простой из них является класс Token.

Token позволяет описать скалярное значение, на изменение которого можно подписаться:

let token = new basis.Token(); // создаем Token
let fn = (value) => console.log('значение изменено на:', value); // функция–обработчик

token.attach(fn); // подписываемся на изменение значения

token.set('привет'); // устанавливаем новое значение
// console> значение изменено на: привет

token.set('habrahabr'); // console> значение изменено на: habrahabr
token.set('habrahabr'); // ничего не выведет в консоль, т.к. значение не отличается от уже установленного

token.detach(fn); // отписываемся от изменений значения

token.set('basis.js'); // новое значение будет установлено, но у токена уже нет подписчиков


Метод Token#attach – добавляет подписчика на изменения значения токена.

Метод Token#detach – удаляет ранее добавленного подписчика.



Более того, один токен может зависеть от другого:

let token = new basis.Token();
let sqr = token.as((value) => value * value); // создаем еще один токен, зависимый от token
let fn = (value) => console.log('значение изменено на:', value);

token.attach(fn);

token.set(4); // console> значение изменено на: 4
console.log(token.get()); // console> 4
console.log(sqr.get()); // console> 16

token.set(8); // console> значение изменено на: 8
console.log(token.get()); // console> 8
console.log(sqr.get()); // console> 64

token.detach(fn);

token.set(10);
console.log(token.get()); // console> 10
console.log(sqr.get()); // console> 100


Token#as – создает новый токен и автоматически подписывает его на изменения значения оригинального токена.

Изменяя значение оригинального токена, оно передается функции, указанной в as и в порожденный токен записывается ее результат.

Таким образом, можно создать цепочку токенов, значение каждого из которых будут зависеть от значения предыдущего токена:

let token = new basis.Token();
let sqr = token.as((value) => value * value);
let twoSqr = sqr.as((value) => value * 2);
let fn = (value) => console.log('значение изменено на:', value);

token.attach(fn);

token.set(4); // console> значение изменено на: 4
console.log(token.get()); // console> 4
console.log(sqr.get()); // console> 16
console.log(twoSqr.get()); // console> 32

token.detach(fn);

token.set(10);
console.log(token.get()); // console> 10
console.log(sqr.get()); // console> 100
console.log(twoSqr.get()); // console> 200


Токен может быть разрушен вызовом метода Token#destroy.

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



Вот такой простой и удобный механизм обновления данных заложен в basis.js.



Давайте посмотрим как используются токены в компонентах basis.js:

let Node = require('basis.ui').Node;
let nameToken = new basis.Token('');

new Node({
container: document.body, // где разместить элемент
template: resource('./template.tmpl'), // шаблон
binding: {
name: nameToken
},
action: { // обработчики событий
input: (e) => nameToken.set(e.sender.value)
}
});


А вот и шаблон:



Привет {name}




Теперь, при вводе данных в текстовое поле, вместо {name} будет подставляться актуальное значение.

Другими словами: свойство Node#binding представляет собой объект, свойствами которого могут быть токены.

Node подписывается на изменения значения таких токенов и своевременно обновляет представление, при чем только те его части, которые реально изменились.



Конечно же не могу обойти вниманием пример с Token#as:

let Node = require('basis.ui').Node;
let nameToken = new basis.Token('');

new Node({
container: document.body,
template: resource('./template.tmpl'),
binding: {
name: nameToken.as(value => value.toUpperCase())
},
action: {
input: (e) => nameToken.set(e.sender.value)
}
});


Уже догадались чтобы будет выведено?



Вы конечно можете возразить, мол:

пппфффф… в ангуляре то же самое делается вообще без единой строчки кода


Да, но позже вы увидите как элегантно basis.js справляется с гораздо более сложными задачами.



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



Спасибо за внимание!



P.S.: если вы, как и я, любите ES6 и хотите использовать его вместе с basis.js, тогда вам понадобится вот этот плагин.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304078/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Позвольте представить, Shadow DOM API на основе слотов

Суббота, 25 Июня 2016 г. 23:05 (ссылка)

Предлагаю вашему вниманию перевод статьи «Introducing Slot-Based Shadow DOM API» автора Ryosuke Niwa, написанную им в блоге WebKit осенью прошлого года.



Мы рады анонсировать что базовая поддержка нового Shadow DOM API на основе слотов, которую мы предлагали в апреле (прим. переводчика: речь идёт об апреле 2015) уже доступна в ночных сборках WebKit после r190680. Shadow DOM это часть Веб Компонентов – набора спецификаций, изначально предложенных Google для того чтобы сделать возможным создание переиспользуемых виджетов и компонентов в вебе. Shadow DOM, в частности, предоставляет легковесную инкапсуляцию DOM дерева, позволяя создавать на элементе параллельное дерево, так называемое «теневое shadow дерево», с помощью которого изменяется отрисовка элемента без изменения DOM. Пользователи такого компонента не смогут ненароком что-то в нём изменить, ведь его shadow дерево не является привычным потомком элемента-хоста. Кроме того, действие стилей также ограничено областью действия (scope), а значит CSS правила, объявленные снаружи shadow дерева не применяются к элементам внутри такого дерева, а правила, объявленные внутри – к элементам снаружи.



Изоляция стилей

Первое значительное преимущество использования shadow DOM – это изоляция стилей. Представим, что мы хотим создать собственный прогресбар. Например, следующим образом мы могли бы использовать два вложенных div'а для того чтобы представить сам прогресбар и ещё один div с текстом, в котором показывать процент выполнения:




Обратите внимание на элемент template, использование которого позволяет автору включить сниппет HTML-текста, чтобы позже быть инстанциированным путём создания клона. Это первая фича «веб компонентов», внедрённая нами в WebKit; позже её включили в спецификацию HTML5. Элементу template в документе разрешено появляться в любом месте (скажем, между table и tr), а содержимое внутри template инертно и не выполняет скриптов и загрузку изображений или любых других ресурсов. Таким образом, пользователю сего прогресбара будет достаточно инстанциировать и обновлять его как показано ниже:

var progressBar = createProgressBar();
container.appendChild(progressBar);
...
progressBar.updateProgress(10);


С такой реализацией прогресбара есть одна проблема: оба его div'а доступны любому желающему, а стили не ограничены только рамками самого элемента. К примеру, стили прогресбара, определённые для CSS класса progress будут так же применены и к следующему HTML:


Pending an approval



А стили других элементов будут переопределять внешний вид прогресбара:


Мы могли бы обойти эти ограничения, дав прогресбару имя custom element, например custom-progressbar чтобы ограничить область действия стилей, а затем проинициализировать все остальные свойства в all: initial, однако в мире Shadow DOM есть более элегантное решение. Основная идея в том, чтобы представить внешний div в качестве дополнительного слоя инкапсуляции так что пользователи не увидят что происходит внутри (создание div'ов для лейбы и самого ползунка), стили прогресбара не будут вмешиваться в работу остальной страницы и наоборот. Для этого нам понадобится сначала создать ShadowRoot, вызвав метод attachShadow({mode: 'closed'}) у прогресбара, а следом вставить в него DOM узлы, необходимые для нашей реализации. Допустим, мы и дальше используем div для задания хоста данному shadow root, тогда мы можем следующим образом создать новый div и приаттачить shadow root:



Обратите внимание, что элемент style находится внутри template и будет склонирован в shadow root вместе с div'ами. Это ограничит область действия стилей этим самым shadow root. Точно так же стили снаружи не применяются к элементам внутри.

Совет: во время дебага может оказаться полезным режим open shadow DOM, при котором shadow root будет доступен через свойство shadowRoot элемента-хоста. Например, {mode: DEBUG ? 'open' : 'closed'}



Копозиция слотов

Внимательный читатель к этому моменту наверняка задался вопросом: почему бы не сделать это средствами CSS и не лезть в DOM? Стилизация это концепция представления, зачем же мы добавляем новые элементы в DOM? На самом деле, первый публичный рабочий черновик CSS Scoping Module Level 1 определяет правило @scope как раз для этих целей. Зачем же понадобился ещё один механизм изолирования стилей? Хорошей причиной для имплементации послужило то, что элементы реализованные внутри компонента скрыты от внешних механизмов обхода узлов, таких как querySelectorAll и getElementsByTagName. Из-за того что по умолчанию узлы внутри shadow root не обнаруживаются этими API, пользователи компонент могут не задумываться о внутренней реализации каждого компонента. Каждый компонент представлен в виде непрозрачного элемента, детали реализации которого инкапсулированы внутри его shadow DOM. Имейте в виду, что shadow DOM никоим образом не заботится о cross-origin ограничениях как это делает элемент iframe. При необходимости другие сценарии смогут проникнуть внутрь shadow DOM. Однако, есть и другая причина по которой появился этот механизм – композиция. Допустим, у нас есть список контактов:


и хотим мы каждому пункту контактной информации из списка добавить красивостей при включённых скриптах:



Вместо того чтобы копировать весь этот текст в наш собственный shadow DOM, мы могли бы следующим образом использовать именованные слоты для отрисовки текста в коде нашего shadow DOM не меняя его:



Концептуально слоты – это незаполненные пробелы в shadow DOM, заполняемые потомками элемента-хоста. Каждый элемент назначается слоту с именем, определённым в атрибуте slot:


Таким образом мы присоединяем к li наш shadow root, а каждый span с атрибутом slot назначается слоту с соответствующим именем внутри shadow DOM. Взглянем подробнее на шаблон shadow DOM:

Name:





Email: Unknown

Address: Unknown
В этом шаблоне имеется два слота с названиями email и address, а также слот с названием fullName, содержащий внутри себя два других слота firstName и lastName. Слот fullName пользуется техникой фолбека, когда firstName и lastName отображаются только в случае отсутствия узлов назначенных fullName. Несмотря на то, что в данном случае каждому слоту назначен ровно один узел, мы могли бы назначить множество элементов с одинаковым атрибутом slot одному и тому же слоту, тогда бы они отображались в том же порядке, в каком они расположены потомками хост-элемента. Можно также использовать безымянные стандартные слоты, их заполнят те потомки хоста, у которых не указан атрибут slot. Когда браузер рендерит этот компонент, содержимое li заменяется на shadow DOM, а слоты внутри него заменяются назначенными узлами так, будто на самом деле отображается следующий DOM:


Как видите, основанная на слотах композиция это мощный инструмент, позволяющий виджетам вставлять в страницу содержимое без клонирования и изменения DOM. С его помощью виджеты могут реагировать на изменения их потомков не прибегая к MutationObserver или каким-либо явным уведомлениям от сценариев. В сущности, композиция превращает DOM в связующий механизм коммуникации между компонентами.



Стилизация хост-элемента

Есть ещё один момент, который стоит отметить в предыдущем примере – мистический псевдокласс :host:


Этот псевдокласс, как следует из его имени, применяется к хосту shadow DOM, в котором находится это правило. По умолчанию, авторские стили снаружи shadow DOM имеют более высокий приоритет в сравнении со стилями внутри shadow DOM. Это сделано чтобы внутри компонента можно было определить «стили по умолчанию», а пользователям компонента дать возможность их переопределять когда нужно. В дополнение, компонент может определить принципиально важные для его отображения стили (такие, например, как ширина или display) с ключевым словом !important. Любые !important правила внутри shadow DOM считаются более приоритетными тех !important, что объявлены снаружи.



Дальнейшая работа

Много работы ещё впереди относительно внедрения Веб Компонентов. Мы бы хотели позволить стилизировать слоты shadow DOM через стили соответствующих внешних узлов. Есть также пожелания научить компоненты встраиваться в тему документа, а также выставлять наружу стилизируемые части в виде псевдоэлементов CSS. В долгосрочной перспективе мы бы хотели увидеть императивный DOM API для манипуляции назначением слотов, мы уже давно предлагали это сделать. А ещё мы заинтересованы в дополнении shadow DOM произвольными (custom) элементами. Вкратце, custom elements API даёт авторам возможность ассоциировать классы JavaScript с конкретным именем элемента в документах HTML; отличный способ идеоматически назначать произвольное поведение и shadow DOM. К сожалению, на данный момент существует несколько противоречивых предложений о том как и когда создавать произвольные элементы. Чтобы помочь направить обсуждение в W3C мы планируем сделать прототип в WebKit. Для сборки пакетов и поставки Веб Компонентов мы работаем над модулями ES6. Как и Mozilla, мы верим что модули радикально изменят отношение авторов к структурированию их страниц. В конечном счёте мы хотели бы спроектировать API создания полностью изолированных веб компонент с подобными iframe политиками безопасности, основанными на shadow DOM и произвольных элементах. В заключение, хотелось бы отметить что мы действительно очень гордимся тем, что значительные возможности Веб Компонентов появляются в WebKit, мы будем и дальше писать о новых появляющихся возможностях. В случае если у вас остались какие-то вопросы обращайтесь напрямую ко мне, @WebKit или к Джону Дэвису.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304112/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

HolyJS: с первой попытки

Суббота, 25 Июня 2016 г. 10:08 (ссылка)

Петербургская JavaScript-конференция HolyJS начиналась почти как авантюра. Затевать совершенно новую конференцию, когда время на подготовку очень ограничено — смелое решение.



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











Конференция была сделана совместными силами: организацией занималась JUG.ru Group, а программу готовили SPB Frontend. Логичное разделение труда: у первых — большой опыт организации других конференций, у вторых — знание JS-мира, позволяющее обеспечить должный уровень докладов.



Впрочем, в открывающем кейноуте от Дениса Мишунова (Digital Garden AS) знание тонкостей JavaScript не требовалось: речь пошла не о них, а о тонкостях человеческого восприятия. Гонясь за миллисекундами и килобайтами, легко позабыть, что на фронтэнде вся эта гонка изначально нужна ради пользователя. А то, насколько будет хорошо пользователю, зависит не только от миллисекунд.







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



Доклад заканчивался отсылкой к документации Apple для разработчиков, в которой напрямую сказано: «The perception of performance is just as effective as actual performance in many cases».







Мишунова на главной сцене сменил Виктор Русакович (GP Software.travel) с докладом о реактивном программировании, и всё сразу стало куда технологичнее. Описав состав RxJS как «объекты, операторы и магия», Русакович подробно прошёлся по второму пункту. Цель «расписать каждый оператор» не ставилась (их попросту слишком много), но конкретные примеры, проиллюстрированные «шариками» с сайта RxMarbles, позволяли получить хорошее общее представление.



Затем Дино Эспозито говорил о распознавании устройств и различном отображении сайтов на них. Он напоминал, что, с одной стороны, user agent string доверять нельзя («как-то мы тестировали дешёвый китайский планшет, так он выдавал себя за iPad»), но с другой, определять параметры устройства и полагаться на responsive web design тоже не панацея («главная проблема в том, что он одинаково обходится с компьютерным окном браузера шириной в 480 пикселов и со смартфоном, у которого ширина экрана 480 пикселов»).







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



Его сменил Михаил Дружинин (Luxoft) с рассказом о порталах на java script: «Бывает нужно разместить на одной странице несколько разных модулей. И если они не зависят друг от друга, то в этом случае ещё повезло...». Но пока Михаил разбирал, как в этом может помочь фреймворк F2, в третьем зале Алексей Симоненко с докладом «Как я перестал верить технологиям» (и завидной бородой) критиковал беготню за новыми фреймворками и прочими инструментами.







С бурным развитием JS-мира неудивительно, что в нём синдром серебряной пули особенно силён: тут чуть ли не каждый день что-то новое обещает исправить все ошибки предшественников и сделать ваш проект гораздо успешнее. Но статья «No Silver Bullet», в этом году отмечающая 30-летие, не стала с момента сочинения менее актуальной. Поэтому неудивительно и появление возражений «куда вы так несётесь, посмотрите на реальных примерах, как переход на что-то новое совершенно не избавлял от всех проблем».



Симоненко оригинально построил доклад, начав с прославления нового чудодейственного средства Hype.js и лишь затем признавшись, что его не существует. Позже он привёл классическую диаграмму The Hype Cycle, напоминающую, что для любой новой технологии характерен «пик завышенных ожиданий», обычно сменяющийся болезненным разочарованием. Поэтому, пока кто-то постоянно прыгает с одной технологии на другую, уже напрыгавшийся и набивший шишек спикер советовал «работайте с тем, что знаете».







В обеденном перерыве, как и накануне на Mobius, можно было услышать обсуждения задач от EPAM. Их набор частично отличался, но задача об инфицированной шахматной доске снова попала в список — и снова обращала на себя внимание. Помимо задач, стенд EPAM запомнился многим возможностью поиграть с развивающим конструктором Qubidoo, заставив шарик катиться по жёлобу. На сайте конструктора написано «от 3 лет до 140 IQ», и это ироничное определение похоже на правду: на HolyJS взрослые мужчины увлечённо возились с игрушкой, способной вызвать интерес у трёхлетнего.



А после обеда Василика Климова (Artec Group) рассказывала про WebGL. Для обычного фронтэндера без опыта работы с 3D-графикой тема может показаться далёкой и пугающей, но Василика объясняла, что бояться нечего: при использовании библиотеки Three.js всё оказывается куда проще, чем можно предположить. От общих слов и эффектных демо-роликов она перешла непосредственно к тому, как пишут шейдеры, и примеры оказались вполне доступными для зрителей без WebGL-опыта: ну да, чтобы превратить цветную модель в чёрно-белую, из трёх цветов по RGB стоит выводить среднее арифметическое, логично.







Помимо отмеченной многими содержательности доклада, он впечатлял ещё и в совсем другом отношении. Пока что на IT-конференциях нечасто можно увидеть, как обаятельная девушка объясняет мужчинам «зря вы боитесь, я разобралась, тут ничего страшного», и кому-то из зрителей такая картина могла рвать шаблон. Но судя по появлению мероприятий вроде Ladies Code, где среди прочих участвовала та же Василика, интерес женщин к IT растёт, и в будущем это может стать куда более привычной картиной.







Затем в том же зале Кирилл Сухомлин (EPAM Systems) говорил о том, откуда берутся новые JS-фичи, и это ярко показывало отличие JS-мира от других. На конференциях DotNext и Mobius не вставал вопрос, откуда берутся новые фичи в .NET или Swift — там сразу ясно, кто всему голова. А в случае с JavaScript о роли Ecma International задумываются куда меньше.



Зато в процессе его развития случаются такие же казусы, как и в других мирах. Как объяснял Кирилл, четвёртая версия ECMAScript была самой амбициозной, но в итоге оказалась заброшенной, и пятую, наоборот, можно было назвать «дуем на воду». Это заставляло вспомнить то, что Дино Эспозито на DotNext говорил о происходящем с (ASP).NET Core: Microsoft устроил революцию, но ещё не доведя её до релиза, испугался результатов и дал по тормозам.



Сам Эспозито тем временем нашёл себе на конференции интересное занятие. На HolyJS, кроме него, был только один англоязычный спикер, так что слушать весь день доклады Дино не мог. Но он обнаружил подходящего собеседника, принявшись болтать с ним и фотографировать его: это был «робот Федя», легко перешедший на английский. Сложно сказать, кто из этой пары выглядел колоритнее и остроумнее.







Закрывал конференцию кейноут от Вячеслава Егорова (Google), работавшего над движком V8. Получалась интересная симметрия с открывающим кейноутом: оба были о производительности, но первый о психологии и восприятии, а второй, наоборот, о технологическом хардкоре и внутренностях движков.



И даже в топ-10 докладов по отзывам зрителей эти два выступления оказались на соседних позициях, уступив только неверию в технологии:



1. Алексей Симоненко — Как я перестал верить технологиям

2. Вячеслав Егоров — Производительность JavaScript через подзорную трубу

3. Денис Мишунов — В погоне за производительностью: психология пользователя

4. Виктор Грищенко — Swarm: синхронизируем рой устройств

5. Николай Рыжиков — JаvaScriрt внутри PostgreSQL

6. Алексей Охрименко — Парсеры — это Спарта

7. Василика Климова — Практическое применение WebGL

8. Роман Дворнов — CSSO: оптимизируем CSS

9. Игорь Зотов — Iskra JS: JаvaScriрt в микроконтроллере

10. Михаил Новиков — Удобные API с GraphQL



Доклад Егорова перекликался с тем, что на Java-конференциях устраивает Алексей Шипилёв: глубокое знание «кишочков» сочеталось с задорным изложением, а суровые числа бенчмарков — с яркими иллюстрациями. Более того, даже в выборе иллюстраций у этих двух спикеров есть пересечения:







На этом выступлении, когда конференция было уже на финишной прямой, внезапно возникла проблема с техникой, и на некоторое время зал остался без слайдов. Как заметил Егоров, прямо перед докладом Алексей 23derevo Фёдоров сказал ему «Раз за всё мероприятие ещё не произошло ни одного технического факапа, значит, на твоём что-то произойдёт, готовься». Забавно было видеть, насколько точными оказались эти слова: фраза из анекдота «стена рухнула точно по графику» получала вполне буквальное воплощение.



Но затем техника ожила, и дело дошло до завершительного слайда «Спасибо». А в остальном конференция прошла удивительно беспроблемно для первого раза, и зрительские отзывы показали: если устраивать HolyJS и было авантюрой, то она явно удалась.




Original source: habrahabr.ru.

https://habrahabr.ru/post/304086/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

HolyJS: с первой попытки

Суббота, 25 Июня 2016 г. 10:08 (ссылка)

Петербургская JavaScript-конференция HolyJS начиналась почти как авантюра. Затевать совершенно новую конференцию, когда время на подготовку очень ограничено — смелое решение.



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











Конференция была сделана совместными силами: организацией занималась JUG.ru Group, а программу готовили SPB Frontend. Логичное разделение труда: у первых — большой опыт организации других конференций, у вторых — знание JS-мира, позволяющее обеспечить должный уровень докладов.



Впрочем, в открывающем кейноуте от Дениса Мишунова (Digital Garden AS) знание тонкостей JavaScript не требовалось: речь пошла не о них, а о тонкостях человеческого восприятия. Гонясь за миллисекундами и килобайтами, легко позабыть, что на фронтэнде вся эта гонка изначально нужна ради пользователя. А то, насколько будет хорошо пользователю, зависит не только от миллисекунд.







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



Доклад заканчивался отсылкой к документации Apple для разработчиков, в которой напрямую сказано: «The perception of performance is just as effective as actual performance in many cases».







Мишунова на главной сцене сменил Виктор Русакович (GP Software.travel) с докладом о реактивном программировании, и всё сразу стало куда технологичнее. Описав состав RxJS как «объекты, операторы и магия», Русакович подробно прошёлся по второму пункту. Цель «расписать каждый оператор» не ставилась (их попросту слишком много), но конкретные примеры, проиллюстрированные «шариками» с сайта RxMarbles, позволяли получить хорошее общее представление.



Затем Дино Эспозито говорил о распознавании устройств и различном отображении сайтов на них. Он напоминал, что, с одной стороны, user agent string доверять нельзя («как-то мы тестировали дешёвый китайский планшет, так он выдавал себя за iPad»), но с другой, определять параметры устройства и полагаться на responsive web design тоже не панацея («главная проблема в том, что он одинаково обходится с компьютерным окном браузера шириной в 480 пикселов и со смартфоном, у которого ширина экрана 480 пикселов»).







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



Его сменил Михаил Дружинин (Luxoft) с рассказом о порталах на java script: «Бывает нужно разместить на одной странице несколько разных модулей. И если они не зависят друг от друга, то в этом случае ещё повезло...». Но пока Михаил разбирал, как в этом может помочь фреймворк F2, в третьем зале Алексей Симоненко с докладом «Как я перестал верить технологиям» (и завидной бородой) критиковал беготню за новыми фреймворками и прочими инструментами.







С бурным развитием JS-мира неудивительно, что в нём синдром серебряной пули особенно силён: тут чуть ли не каждый день что-то новое обещает исправить все ошибки предшественников и сделать ваш проект гораздо успешнее. Но статья «No Silver Bullet», в этом году отмечающая 30-летие, не стала с момента сочинения менее актуальной. Поэтому неудивительно и появление возражений «куда вы так несётесь, посмотрите на реальных примерах, как переход на что-то новое совершенно не избавлял от всех проблем».



Симоненко оригинально построил доклад, начав с прославления нового чудодейственного средства Hype.js и лишь затем признавшись, что его не существует. Позже он привёл классическую диаграмму The Hype Cycle, напоминающую, что для любой новой технологии характерен «пик завышенных ожиданий», обычно сменяющийся болезненным разочарованием. Поэтому, пока кто-то постоянно прыгает с одной технологии на другую, уже напрыгавшийся и набивший шишек спикер советовал «работайте с тем, что знаете».







В обеденном перерыве, как и накануне на Mobius, можно было услышать обсуждения задач от EPAM. Их набор частично отличался, но задача об инфицированной шахматной доске снова попала в список — и снова обращала на себя внимание. Помимо задач, стенд EPAM запомнился многим возможностью поиграть с развивающим конструктором Qubidoo, заставив шарик катиться по жёлобу. На сайте конструктора написано «от 3 лет до 140 IQ», и это ироничное определение похоже на правду: на HolyJS взрослые мужчины увлечённо возились с игрушкой, способной вызвать интерес у трёхлетнего.



А после обеда Василика Климова (Artec Group) рассказывала про WebGL. Для обычного фронтэндера без опыта работы с 3D-графикой тема может показаться далёкой и пугающей, но Василика объясняла, что бояться нечего: при использовании библиотеки Three.js всё оказывается куда проще, чем можно предположить. От общих слов и эффектных демо-роликов она перешла непосредственно к тому, как пишут шейдеры, и примеры оказались вполне доступными для зрителей без WebGL-опыта: ну да, чтобы превратить цветную модель в чёрно-белую, из трёх цветов по RGB стоит выводить среднее арифметическое, логично.







Помимо отмеченной многими содержательности доклада, он впечатлял ещё и в совсем другом отношении. Пока что на IT-конференциях нечасто можно увидеть, как обаятельная девушка объясняет мужчинам «зря вы боитесь, я разобралась, тут ничего страшного», и кому-то из зрителей такая картина могла рвать шаблон. Но судя по появлению мероприятий вроде Ladies Code, где среди прочих участвовала та же Василика, интерес женщин к IT растёт, и в будущем это может стать куда более привычной картиной.







Затем в том же зале Кирилл Сухомлин (EPAM Systems) говорил о том, откуда берутся новые JS-фичи, и это ярко показывало отличие JS-мира от других. На конференциях DotNext и Mobius не вставал вопрос, откуда берутся новые фичи в .NET или Swift — там сразу ясно, кто всему голова. А в случае с JavaScript о роли Ecma International задумываются куда меньше.



Зато в процессе его развития случаются такие же казусы, как и в других мирах. Как объяснял Кирилл, четвёртая версия ECMAScript была самой амбициозной, но в итоге оказалась заброшенной, и пятую, наоборот, можно было назвать «дуем на воду». Это заставляло вспомнить то, что Дино Эспозито на DotNext говорил о происходящем с (ASP).NET Core: Microsoft устроил революцию, но ещё не доведя её до релиза, испугался результатов и дал по тормозам.



Сам Эспозито тем временем нашёл себе на конференции интересное занятие. На HolyJS, кроме него, был только один англоязычный спикер, так что слушать весь день доклады Дино не мог. Но он обнаружил подходящего собеседника, принявшись болтать с ним и фотографировать его: это был «робот Федя», легко перешедший на английский. Сложно сказать, кто из этой пары выглядел колоритнее и остроумнее.







Закрывал конференцию кейноут от Вячеслава Егорова (Google), работавшего над движком V8. Получалась интересная симметрия с открывающим кейноутом: оба были о производительности, но первый о психологии и восприятии, а второй, наоборот, о технологическом хардкоре и внутренностях движков.



И даже в топ-10 докладов по отзывам зрителей эти два выступления оказались на соседних позициях, уступив только неверию в технологии:



1. Алексей Симоненко — Как я перестал верить технологиям

2. Вячеслав Егоров — Производительность JavaScript через подзорную трубу

3. Денис Мишунов — В погоне за производительностью: психология пользователя

4. Виктор Грищенко — Swarm: синхронизируем рой устройств

5. Николай Рыжиков — JаvaScriрt внутри PostgreSQL

6. Алексей Охрименко — Парсеры — это Спарта

7. Василика Климова — Практическое применение WebGL

8. Роман Дворнов — CSSO: оптимизируем CSS

9. Игорь Зотов — Iskra JS: JаvaScriрt в микроконтроллере

10. Михаил Новиков — Удобные API с GraphQL



Доклад Егорова перекликался с тем, что на Java-конференциях устраивает Алексей Шипилёв: глубокое знание «кишочков» сочеталось с задорным изложением, а суровые числа бенчмарков — с яркими иллюстрациями. Более того, даже в выборе иллюстраций у этих двух спикеров есть пересечения:







На этом выступлении, когда конференция было уже на финишной прямой, внезапно возникла проблема с техникой, и на некоторое время зал остался без слайдов. Как заметил Егоров, прямо перед докладом Алексей 23derevo Фёдоров сказал ему «Раз за всё мероприятие ещё не произошло ни одного технического факапа, значит, на твоём что-то произойдёт, готовься». Забавно было видеть, насколько точными оказались эти слова: фраза из анекдота «стена рухнула точно по графику» получала вполне буквальное воплощение.



Но затем техника ожила, и дело дошло до завершительного слайда «Спасибо». А в остальном конференция прошла удивительно беспроблемно для первого раза, и зрительские отзывы показали: если устраивать HolyJS и было авантюрой, то она явно удалась.




Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304086/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<javascript - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda