Человек Разумный — всегда пугал исследователей своей непостижимостью. Все эти эмоции, перебивающие логику; эти древние инстинкты, доминирующие над рациональным поведением; плюс еще детские депривации и непредсказуемые подсознательные ассоциации.

— Да, вот как со всем этим работать?

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

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

Нельзя войти в реку не замочив ног

Почему так важно было написать эту стотысячную статью про “поворот лицом к простому пользователю”, которыми уже лет пять как завален весь интернет. Да потому, что простого поворота дизайнерской головы в другую сторону явно недостаточно. Нужны новые смелые подходы.

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

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

— Но почему так сложно? Человек же сам расскажет.

Человек — не видеокамера, и может рассказать, только слегка приукрасив; а написать, чуточку приврав. Но ничего писать и говорить в хорошем интерфейсе его потребитель не должен, только использовать его по назначению.

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

В хорошо заданном вопросе всегда содержится 90% ответа, и значит, что по-настоящему хорошо подготовив вопросы — дизайнер уже знает все ответы на них. Но слова ничего не стоят, когда есть поступки.

— А можно тут уточнить? А что если… хотя нет, спасибо, уже не нужно.

Пишите — не пишите

Год назад показалось, что спасение первичного НЕзнания проектировщика может быть и в текстовых интерфейсах. Мол, читать и писать с помощью клавиатуры люди в своей массе уже обучены и привыкли, а значит, им будет довольно просто превратить в связный текст любые свои желания и потребности.

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

— Нет, надо так: сделай, чтобы все в мире были сыты и счастливы! Вжух!

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

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

Мы Можем Многое

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

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

UX-дизайнер по прежнему ищет ответ на вопрос “куда человек смотрит”, а не “как он осознает (трактует, интерпретирует, оценивает физиологически (включая реакцию потовых желез, изменения мышечного тонуса и размера зрачков) — тот единственный графический объект, который в эту миллисекунду находится в фокусе его внимания”

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

— И почему же? Слишком дорого?

В центре внимания — торговый центр

Вы когда нибудь-задумывались, для чего сегодня люди ходят в торговые центры? Не проводя беглые анкетирования, а просто пару недель молча побродив среди тысяч людей. Они способны в любой рабочий день за секунду купить себе пару носков, но тратят на это же самое целиком свой законный выходной день. Зачем выбрасывать свой долгожданный выходной — на блуждание по коридорам, на муки выбора, на бесконечный анализ соотношения цена\качество?

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

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

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

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

— Люди не воспринимают карты, не понимают цифры — они их обдумывают и осознают постепенно и не целиком.
— Люди не считывают мгновенно мысль с инфографики, из таблицы или сводки. Мы их видим, мы их осмысливаем умом, но не воспринимаем мгновенно. Потому, что это вторая сигнальная система, тонкий недооформившийся слой поверх стабильных многовековых рефлексов,
— Люди хотят информацию из простых глаголов: Беги, Кусай, Нале-во, Голосуй сердцем…

Поэтому так бесполезно расспрашивать напрямую: “А каких еще функций со свайпами, пушами, вейпами и крафтовыми скруглениями — вам не хватает в жизни”. Просите совершить поступок:

Человеческое время и память телефона — вот два ресурса, на которые покушается каждая ваша новая разработка, так проанализируйте, на чье место в человеческом распорядке дня вы претендуете. Замерьте, на сколько градусов изменится температура пользователя после предложения потеснить Цукерберга в своей жизни. Вот это и будет уже первый настоящий неподдельный UX.

Юзабилити прошлого

До возникновения болезненного стереотипа о том, что люди взаимодействуют с миром только через визуальные символы, — проводить натурные исследования user experience было куда интереснее. Например, на протяжении многих веков на восточных базарах получение нужной цены за товар было целым поединком, баттлом, версусом между хитрым торговцем и ушлым покупателем. Бывало, весь город сбегался смотреть на очередное шоу по поводу выбивания скидки, скандируя “Пятнадцатый век, пятнадцатый век”.

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

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

Наша жизнь наполняется смыслом только в процессе поиска чего-либо, во время пути к манящей вдалеке размытой цели. Нет ничего лучше предчувствия удачи, когда мы еще точно не знаем, чем же одарит нас судьба через пару секунд — вкусной добычей или стаей хищников. В этом и есть наша жизнь, цель и страсть. В этом интерес, элемент геймификации. Тот из дизайнеров, кто через 15-20 лет первым осознает это — получит себе весь рынок целиком.

Конечно, имеющиеся сегодня примитивные анкетирования якобы показывают, что люди сами просят больше информации о всех товарах и скидках; и еще чатик с теми, кто совершает покупку в соседней примерочной; и еще опцию “Тревожная кнопка” в приложении мегамаркета для вызова охраны (удобно же: достал телефон, поймал вайфай, скачал приложение, запустил, перешел в меню, кликнул о том, что у человека в коридоре инсульт — всего 15 минут стараний ради помощи человеку), а еще людям так нужна удобная навигация, ведь они не хотят плутать, а за 3 секунды найти и купить нужный товар…

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

Так как же улучшить и упростить покупателям их выходной день в торговом центре с помощью современных технологий, как не упрощая им саму покупку товара?

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

ВЫ СЛЫШИТЕ МЕНЯ, ОТЕЧЕСТВЕННЫЕ МАГИСТРЫ ЮЗАБИЛИТИ?

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

Ищите женщину (еще одна практика)

Представьте внезапный выброс эндорфинов у обывателя, внезапно нашедшего на земле кошелек с деньгами. Сопоставима ли она с рассылкой на email, что прямо сейчас где-то в Алтуфьево человек потерял кошелек? А затем проведите эксперимент:

а) Сначала просто сообщите своей жене, что завтра в Милане в одном из магазинов красное платье будет стоит на 15 % дешевле обычного и понаблюдайте, кинется ли она заказывать билеты, чтобы лететь за этой покупкой. Зафиксируйте на видео ее поведение, запишите все поисковые запросы вечером, оцените зрачки и потовые железы.

б) Через месяц просто купите жене билеты в Милан на шоппинг ничего более не упоминая. Запишите ее реакцию по возвращению, ее зрачки, ее рассказ о том, как она “случайно в одном бутике нашла это премилое платьице со скидкой в 15%”.

Затем сравните две видеозаписи.

Расходы одинаковые, полученный результат идентичен, так почему же на видео перед вами практически две разные женщины с разной осанкой и даже походкой: счастливая от добычи пантера и обычная домохозяйка?

Собственно, после нахождения ответов на вышеуказанные вопросы, каждому из вас можно смело присваивать титул Министра-Магистра по дизайну, юзабилити и социологии, потому что один этот эксперимент говорит о природе живых людей в сто раз больше, чем все имеющиеся сегодня в интернете статьи о методе Персонажей и выдумывании из головы разнообразных flow и даже customer journey maps.

— Но какое на основании этих данных тогда нужно создавать приложение?

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

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

Так почему бы не проверить теорию, что взрослые тоже подсознательно больше хотят прикасаться не к плоской поверхности смарфона, смахивая очередное уведомление, а к телам. В идеале, конечно, к телам живых манекенщиц: “Мне бы вот такие трусики жене на 8 марта купить с кружевами вот тут”.

Кто знает, что будет в итоге, кто тестировал, кто хотя бы пытался выйти за рамок пуш-уведомлений? Время первых на этом рынке еще не наступило. Теория еще ни разу не была вытеснена практикой. И это просто мега-разочарование.

Благодарю за уделенное время!
ссылка на оригинал статьи https://habrahabr.ru/post/327646/

Привет, Хабрахабр! По какой-то причине, последнее время никого не удивляет expressjs под капотом каждого второго фреймворка на node.js, но действительно ли он нужен там? Я не говорю про то, что expressjs — это плохо, нет, он справляется со своими задачами, но когда мне понадобился роутинг сложнее чем может дать этот фреймворк, я задумался, а что есть еще в expressjs чтобы его оставить в проекте? К сожалению, кроме webserver в нем нет ничего, интеграция с шаблонизатарами — это мелочь, да и middleware сводятся к простому набору функций, кучи callback hell.

Если открыть доку по node.js и мельком посмотреть на то количество модулей, которые есть в ядре, — можно открыть много нового для себя. Как вы уже догадались, речь пойдет про очередной велосипед.

Сразу скажу, что многие финты были позаимствованы с php-фреймворков.

Зависимости, которые я все же оставил в проекте:

async, hashids, mime-types, sequelize, validator, pug

1) давайте определимся со структурой проекта:

2) Как запустить web приложение:

Создадим файл bin/server.js

import Application from "dok-js/dist/web/Application"; import path from "path";  const app = new Application({   basePath: path.join(__dirname, ".."),   id: "server" }); app.run();  export default app; 

После чего наше приложение будет пытаться загрузить конфинг из ./config/server.js

import path from "path"; export default function () {   return {     default: {       basePath: path.join(__dirname, ".."),       services: {         Database: {           options: {             instances: {               db: {                 database: "example",                 username: "example",                 password: "example",                 params: {                   host: "localhost",                   dialect: "postgres"                 }               }             }           }         },         Server: {           options: {             port: 1987           }         },         Router: {           options: {             routes: {               "/": {                 module: "dashboard",                 controller: "index",                 action: "index"               },               "/login": {                 module: "identity",                 controller: "identity",                 action: "index"               },               "/logout": {                 module: "identity",                 controller: "identity",                 action: "logout"               },               "GET /assets/<filePath:.*>": {                 module: "static",                 controller: "static",                 action: "index",                 params: {                   viewPath: path.join(__dirname, "..", "views", "assets")                 }               },               "/<module:\w+>/<controller:\w+>/<action:\w+>": {}             }           }         }       },       modules: {         identity: {           path: path.join(__dirname, "..", "modules", "identity", "IdentityModule")         },         dashboard: {           path: path.join(__dirname, "..", "modules", "dashboard", "DashboardModule")         }       }     }   }; } 

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

Теперь боль номер два: контроллеры и экшены, которые нам навязывает expressjs и большинство nodejs-фреймворков. Это как правило анонимная функция (я понимаю, что это нужно для производительности), которая на вход получает request и response и делает с ними все что угодно, т.е. если вам нужно будет в середине проекта воткнуть логгер, к примеру, для логирования всех респонзов, будь добр прорефакторить почти все приложение, и не дай бог пропустить вызов колбека который делает next(request, response), это я к тому, что никогда не знаешь в какой момент времени твой экшен закончил свое выполнение.

Решение, которое я предлагаю:

async run(ctx) {     this.constructor.parse(ctx);     try {       ctx.route = App().getService("Router").getRoute(ctx.method, ctx.url);     } catch (e) {       return App().getService("ErrorHandler").handle(404, e.message);     }      try {       return App().getModule(ctx.route.moduleName).runAction(ctx);     } catch (e) {       return App().getService("ErrorHandler").handle(500, e.message);     }   } 

async runAction(ctx) {     const {controllerName, actionName} = ctx.route;     const controller = this.createController(controllerName);     if (!controller[actionName]) {       throw new Error(`Action "${actionName}" in controller "${controllerName}" not found`);     }      const result = await this.runBehaviors(ctx, controller);     if (result) {       return result;     }     return controller[actionName](ctx);   } 

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

Ну и сам контроллер:

import Controller from "dok-js/dist/web/Controller"; import AccessControl from "dok-js/dist/behaviors/AccessControl"; export default class IndexController extends Controller {    getBehaviors() {     return [{       behavior: AccessControl,       options: [{         actions: ["index"],         roles: ["user"]       }]     }];   }    indexAction() {     return this.render("index");   } } 

import Controller from "dok-js/dist/web/Controller"; import SignInForm from "../data-models/SignInForm";  export default class IdentityController extends Controller {    async indexAction(ctx) {     const data = {};     data.meta = {       title: "Авторизация"     };      if (ctx.method === "POST") {       const signInForm = new SignInForm();       signInForm.load(ctx.body);       const $user = await signInForm.login(ctx);       if ($user) {         return this.redirectTo("/", 301);       }       data.signInForm = signInForm;     }      return this.render("sign-in", data);   }    logoutAction(ctx) {     ctx.session.clearSession();     return this.redirectTo("/", 302);   }  } 

Так же сразу скажу, что конструктор контроллера вызывается 1 раз и затем складывается в кеш.

Сам фреймворк еще сыроват, но на него можно посмотреть на гитхабе:

github.com/kalyuk/dok-js

Также набросал небольшой пример, там есть еще консольное приложение, котрое запускает миграции:

github.com/kalyuk/dok-js-example
ссылка на оригинал статьи https://habrahabr.ru/post/327638/

Введение

Динамические веб приложения (SPA, Single Page Applications) становятся все более популярными. Их использование позволяет упростить и ускорить разработку и поддержку за счет следующий преимуществ:

• не требуется server-side рендеринг;
• сайт — это набор статических файлов (html, js, css, images, fonts), которые лежат на CDN;
• нет затрат на масштабирование frontend;
• код frontend локализован в одном проекте. (Раньше часть кода была на server-side, часть в frontend.);
• уменьшение затрат на разработку backend (только API);
• уменьшение нагрузки на backend (только API запросы);
• возможность вместо собственного backend использовать сервисы типа (https://scaphold.io), микросервисы, lambda.

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

Большой нерешенной проблемой SPA является их полная несовместимость с веб краулерами поисковых систем (индексация сайтов) и социальных сетей (sharing в соц. сетях). На текущий момент краулеры не выполняют на своей стороне javascript и поэтому не могут получить содержимое SPA в виде html кода. В 2015 году Google официально отказался от поддержки выполнения javascript кода на своей стороне (https://webmasters.googleblog.com/2015/10/deprecating-our-ajax-crawling-scheme.html).

Решения

Сегодня есть несколько типов решений для проектов, которые хотят полноценно разрабатывать SPA.

Поддержка собственного server-side рендеринга

Что это такое

Это старый подход к организации веб приложения при котором сохраняется server-side рендеринг html страниц. Когда загружается SPA в браузере клиента, обычно, сначала приложение удаляет весь html код, созданный сервером, и его место заполняется результатом работы программы. На текущий момент это наиболее часто используемое решение.

Чем это хорошо

• это работает;
• все свое.

Чем это плохо

• удорожает и замедляет разработку за счет необходимости дважды реализовывать одни и те же функции на сервере и клиенте;
• удорожает поддержку и масштабирование, т.к. требуется управлять и обслуживать веб-сервера;
• увеличивает вероятность отказов, ошибок, сбоев.

Изоморфный рендеринг

Что это такое

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

Чем это хорошо

• работает на очень простых приложениях, типа "hello world";
• не требует дважды реализовывать одни и те же функции на сервере и клиенте.

Чем это плохо

• не работает на проектах сложнее "hello world", которые требуют работы с динамически загружаемым контентом, управлением очередями запросов, websocket подписками на обновления данных;
• удорожает разработку, т.к. не работает из коробки, по факту все равно требуется дополнительно разбираться с серверным кодом;
• удорожает поддержку и масштабирование, т.к. требуется управлять и обслуживать веб-сервера.

Prerender.io (https://prerender.io/)

Что это такое

Это сервис с открытым исходным кодом, который позволяет организовать перенаправление трафика от краулеров на специальный браузер, который выполняет javascript код и вернет статическую html страницу. В качестве браузера используется PhantomJS.

Чем это хорошо

• open-source (можно развернуть у себя и не платить за Cloud решение, на деле получается дороже);
• работает для сложных проектов;
• умеет правильно отдавать 404, 301 из <meta name="prerender-status-code" content="404"> (https://prerender.io/documentation/best-practices);
• снижает затраты на разработку (требуется только frontend);
• снижает затраты на поддержку (frontend можно раздавать с cdn, как набор статики).

Чем это плохо

• платный;
• медленный на сложных проектах. Краулеры часто не дожидаются ответа. Причем, если умный краулер google через некоторое время попробует еще раз получить содержимое страницы, то пользователь социальной сети, который хотел поделиться со своими друзьями интересным контентом вашего сайта и недождался ответа, потерян навсегда.
• на сложных проектах краулеры почти всегда получают cached pages. Т.е. почти всегда получают старую информацию и со второго раза.
• иногда требует дополнительных усилий от разработки;
• если что-то не работает, очень трудно отлаживать;
• регулярная переиндексация страниц для cache создает дополнительную нагрузку на backend;
• требует наличия web server для интеграции.

Способы интеграции

Предлагает множество однотипных интеграций для разных фрейморков и веб серверов. Они заключаются в проксировании трафика от краулеров на prerender.io (если в заголовке запросов UserAgent соответствует краулеру или в параметрах запроса есть _escaped_fragment_). Остальной трафик отдается в обычном режиме (набор статики).

Renderjs.io (https://renderjs.io)

Что это такое

Cloud based сервис, который работает аналогично prerender.io, но работает быстро, не использует cache, использует последнюю версию Chromium.

Как это работает

После первой загрузки SPA приложения в современных браузерах работают очень быстро. Для отрисовки новой страницы обычно требуется всего несколько запросов. Renderjs.io — сервис, который делает это для браузеров. Для рендеринга используется Chromium browser. При первом обращении краулера в настоящем, реальном Chromium открывается закладка с веб приложением. Эта закладка не закрывается долгое время. При обращении по новому url не происходит полной загрузки всего, а лишь pushState в уже загруженное приложение. Таким образом рендеринг работает очень быстро и очень легко отлаживать, если у вас в Chromium работает — работает и на Renderjs.io.

Чем это хорошо

• работает для сложных проектов;
• умеет правильно отдавать 404, 301 из <meta name="status-code" content="404">;
• снижает затраты на разработку (требуется только frontend);
• снижает затраты на поддержку (frontend можно раздавать с cdn, как набор статики);
• работает быстро;
• для рендеринга использует Chromium;
• не использует cache — страницы всегда содержат актуальную информацию;
• позволяет подключиться за 5 минут используя DNS интеграцию.

Чем это плохо

• не open-source;
• работает только внутри приложения. Т.к. для смены url используется history.pushState то выход за границы приложения работать не будет.

Способы интеграции

Интеграция при помощи middleware аналогична prerender.io.

Интеграция при помощи DNS записи. При этом способе интеграции проект перенаправляет весь свой трафик на cdn.renderjs.io и получает полноценную обработку трафика от краулеров через рендер сервис, а остальной трафик на свой веб сервис. Этот способ позволяет небольшим проектам за 5 минут сделать свой SPA доступным для поисковых систем и заниматься более важными делами.

Выполните несколько простых шагов:

1. Зарегистрируйтесь;
2. Создайте новый проект;
3. Заполните поля. Domain — это поле название домента (mysite.com), с которого будут приходить запросы, а поле origin — это url (обычно хостера mysite.github.io) по которому лежит ваше приложение;
4. Создайте на вашем DNS сервисе запись CNAME mysite.com -> cdn.renderjs.io;
5. Проверьте ваше приложение (в терминале curl http://mysite.com или в браузере view-source:http://mysite.com/?_escaped_fragment_=);
6. Если все правильно, получите отрендеренный html.

Частые вопросы

Q: А почему не отдавать всем клиентам готовый html код?
A: По нескольким причинам:

• без поддержки javascript клиент все-равно не сможет полноценно пользоваться приложением, так что лучше отдавать какой-нибудь fallback.html с надписью включите javascript;

• рендеринг требует времени — это все-таки дольше, чем получить набор статики (html, js, css) с cdn.

  Q: Как индексировать закрытые разделы, которые требуют cookies?
  A: Технически это возможно, но на практике не требуется.

Выводы

Мы считаем, что для молодых проектов на начальном уровне использование renderjs.io и DNS интеграции — идеальное решение, которое позволяет одновременно получить все преимущества полноценного SPA и сосредоточиться на решении действительно важных задач, а именно создании ценности для клиента.

Новые проекты с трафиком тоже могут использовать renderjs.io с DNS интеграцией или nginx интеграцией.

Большие, успешные проекты пусть думают самостоятельно. Если есть желание бороться проблемами, которые уже решены, что ж они большие — сами знают, что делать.

О нас

purelab.io — Мы команда профессиональных разработчиков. Специализируемся на разработке высококачественных и современных веб приложений на базе ReactJS. Используем функциональное программирование. Имеем собственные решения для того, что бы делать вещи правильно. Можем помочь, проконсультировать, разработать. Пишите, будем рады.

ссылка на оригинал статьи https://habrahabr.ru/post/327612/

Китай известен своей жесткой регуляторной политикой в отношении Интернета. Здесь недоступны многие сервисы, привычные жителям других стран. Это, например, Twitter, Google, YouTube, вместо которых пользователи Поднебесной используют отечественные аналоги. Всего в КНР заблокированы 135 из 1000 самых популярных мировых сайтов. Еще в 2009 году правительство этой страны запретило регистрацию частными лицами доменных имен в произвольном порядке. Для этого нужно получить специальное разрешение. Китайские сайты подвергаются тщательной проверке, чтобы не допустить выхода во внутреннюю сеть запрещенной или нежелательной информации.

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

По информации агентства Синьхуа, которое ссылается на министерство культуры КНР, теперь при регистрации в онлайн-играх пользователей обяжут вводить данные из собственных удостоверений личности, с использованием реальных имен. Плюс ко всему, операторы онлайн-игр обязаны теперь хранить информацию о своих пользователях. Делается это для того, чтобы предоставить все данные надзорным органам, в том случае, если они потребуются чиновникам.

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

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

Число пользователей интернета в Китае к концу 2016 года достигло 731 миллиона человек. При этом коэффициент охвата составляет 53,2%, это на 3,1% больше, чем средний показатель по миру. За прошлый год в Китае количество пользователей сети выросло на 6,2%, это 42,99 миллиона человек.
ссылка на оригинал статьи https://geektimes.ru/post/288730/

Несмотря на то, что Altium Designer поставляется с огромными библиотеками компонентов по-прежнему остается необходимость создания в нем своих схемных компонентов. Особенно это актуально для крупных компонентов с большим количеством выводов и атрибутов выводов. Это могут быть FPGA, микроконтроллеры, процессоры, чипы памяти и т.д. Здесь я представлю свою технологию генерации компонентов экстрагируя информацию из PDF файлов.

Возьмем для примера даташиты на микроконтроллеры Kinetis, скажем серию K66. Нет труда извлечь схемные компоненты этих микроконтроллеров из многочисленных референс-дизайнов предоставляемых фирмой производителем. К счастью многие из них представлены в формате Altium Designer. Скачиваем отсюда архив «Hexiwear-Design-Files», находим там схему, а в ней вот такое представление компонента:

(Кликнуть для увеличения)

Здесь схемный компонент микроконтроллера разбит на несколько логических частей, так как было удобно автору схемы. Остается только завидовать профессионализму автора, но обычно такое скупое представление компонента затрудняет понимание работы схемы, а в последствии и поиск ошибок.
Микроконтроллер на своих выводах может поддерживать до 7-и альтернативных функций. Ошибись схемотехник в назначении функции хотя бы одного вывода и плату придется мучительно тюнинговать вручную после изготовления или даже выкинуть, если корпус — BGA.
Поэтому такой компонент мы не можем позаимствовать. Он к тому же представлен только для одного корпуса, а корпуса могут быть и другие, с другой распиновкой.
Не лучше обстоят дела и у компонентов микроконтроллеров, найденных в сторонних библиотеках. В них также не указываются альтернативные функции.

Я нашел выход в автоматизации генерации компонентов из pdf даташитов.
Шаг 1.
Определяем какими таблицами в даташите представлена распиновка. Для K66 она представлена в виде такой таблицы простирающейся на несколько листов.

(Кликнуть для увеличения)

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

Шаг 2.
Из PDF файла переносим таблицы в MS Excel. Я использовал для этого программу Adobe Acrobat. У нее существует бесплатная триальная версия.
Получаем таблице в Excel такого вида:

(Кликнуть для увеличения)

Шаг 3.
Экспортирую таблицу из Excel в текстовый файл где поля таблицы разделены символом табуляции (0x09).
Шаг 4.
Полученный нами файл таблицы наполнен всяческим мусором, унаследованным от форматирования в PDF файле. Это и ненужные переносы строк, и пробелы, и другие ненужные символы.
Поэтому я написал программу в Delphi которая импортирует файл и фильтрует мусор.

(Кликнуть для увеличения)

В окне программы указывается путь к файлу альтернативных функций портов (это экспортированная из Excel наша таблица), указывается тип корпуса микросхемы (список заполнен в программе на Delphi вручную), указывается директория и файл куда будет сконвертирована таблица в формат пригодный для последующего импорта в Altium (это должен быть файл с расширением .csv). Сепаратором для csv файла должна быть запятая. А разделяющий функции символ может быть произвольный, такой чтобы удобно читались перечисления функций в описании вывода.
Все правильно настроив нажимаем «Выполнить».
После успешного выполнения увидим в закладке «Выходная таблица для Altium» таблицу, предназначенную для обработки скриптом Altium Designer. Таблица сохранена в указанном ранее csv файле.

(Кликнуть для увеличения)

Шаг 5.
Открываем Altium Designer. Открываем библиотеку схемных компонентов где хотим создать новый компонент. Щелкаем последовательность DXP -> Run Script. Указываем путь к скрипту ImportPins.PRJSCR. Появляется такое окно:

(Кликнуть для увеличения)

В нем щелкаем RunImportPins. В появившемся диалоге указываем путь к нашему csv файлу и щелкаем Update Mapping. Получаем окно со следующим содержанием.

Щелкаем Execute и в окне редактора схемного компонента получаем изображение всех выводов с присвоенными им названиями и номерами:

(Кликнуть для увеличения)

Все! Работа сделана.

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

Репозиторий проекта находится здесь.
В директории Pin_builder_MK66 находятся все файлы для повторения шагов и их результаты, описанные в этой статье. Там же исходные файлы конвертера на Delphi. В директории Import_pins_Altium_script находится проект скрипта для Altium Designer.
В файле FunctionsMapping.xlsx содержится исходная таблица, экспортированная из даташита.
csv файл для конвертации называется MK66FN2M0VLQ18.csv
ссылка на оригинал статьи https://habrahabr.ru/post/327628/