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


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

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

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

[Перевод] Валидация JSON из командной строки Linux

Четверг, 21 Июля 2016 г. 15:25 (ссылка)

Вследствие синтаксической простоты и гибкости, JSON (JavaScript Object Notation, Объектная Нотация JavaScript) стал стандартом де-факто, используемым для обмена данными во многих веб-приложениях. В связи с тем, что JSON широко используется для представления структурированных данных с высокой степенью гибкости, возникает необходимость иметь возможность «валидировать» JSON-представления.



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







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



Валидация данных JSON по схеме JSON из командной строки



Есть много библиотек и утилит с открытым исходным кодом, которые погут валидировать данные JSON. Одна из них — это библиотека JSON-Spec на python, которая идет с утилитой командной строки json.



Чтобы установить JSON-Spec на Linux, для начала установите pip, а затем установите ее, как показано далее.



$ sudo pip install json-spec


Затем вы можете валидировать данные JSON по схеме JSON в следующей форме:



$ json validate --schema-file=schema.json --document-file=data.json


$ json validate --schema-file=schema.json < data.json


$ json validate --schema-file=schema.json --document-json='{"foo": ["bar", "baz"]}'


Давайте используем следующие примеры данных JSON и схемы JSON и посмотрим, как данные JSON могут быть валидированы по схеме JSON.



data.json:



{
"id" : 1,
"name": "Dan Nanni",
"age": 25,
"skills": ["написание скриптов", "работа в дата-центре"]
}


schema.json:



{
"title": "Работник",
"description": "Информация о работнике",
"type": "object",
"properties": {
"id": {
"description": "Уникальный идентификатор работника",
"type": "integer"
},
"name": {
"description": "Имя работника",
"type": "string"
},
"age": {
"type": "number",
"minimum": 0,
"exclusiveMinimum": true
},
"skills": {
"type": "array",
"items": {
"type": "string"
},
"minItems": 1,
"uniqueItems": true
}
},
"required": ["id", "name", "age"]
}


Взяв приведенные выше примеры, валидируйте data.json по schema.json, как показано далее.



$ json validate --schema-file=schema.json --document-file=data.json


Если данные JSON соответствуют схеме, команда ничего не выдаст. Если нет, команда выдаст исключение:



Exception: document does not validate with schema.

#/
- reason Missing property


Исключение: документ не соответствует схеме.

#/
- причина Отсутствующее свойство


Валидация схемы JSON из командной строки



Еще один аспект валидации JSON — это проверять соответствует ли сама схема JSON правильному синтаксису. Для валидации схемы пригодится инструмент на Java под названием json-schema-validator. Этот инструмент поддерживает валидацию синтаксиса для самой последней 4-й версии черновика схемы JSON. Он может работать независимо из командной строки или может быть интегрирован в процесс сборки Maven как плагин.



Для запуска его из командной строки вы можете скачать исполняемую версию JAR из Bintray. Убедитесь, что скачиваете архив json-schema-validator-X.X.X-lib.jar, в который включены все зависимости.



После скачивания, проверьте валидность схемы JSON из командной строки, как показано далее.



$ java -jar json-schema-validator-2.2.6-lib.jar --syntax schema.json


--- BEGIN /home/dan/schema.json---
validation: SUCCESS
--- END /home/dan/schema.json---


--- НАЧАЛО /home/dan/schema.json---
валидация: УСПЕШНО
--- КОНЕЦ /home/dan/schema.json---

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

https://habrahabr.ru/post/306140/

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

Звезды в музыкальной гостиной. «The Real Group»

Четверг, 14 Июля 2016 г. 17:57 (ссылка)















The Real Group - это профессиональная вокальная группа из Швеции, поющая а-капелла, т.е. без использования любых других инструментов, кроме собственных голосов. Этот коллектив, образовавшийся уже 23 года назад и сейчас постоянно развивается. TRG и сегодня в числе лучших в мире вокальной музыки.

















 


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

Последние новости о развитии C++

Среда, 13 Июля 2016 г. 19:19 (ссылка)

Недавно в финском городе Оулу завершилась встреча международной рабочей группы WG21 по стандартизации C++, в которой впервые официально участвовали сотрудники Яндекса. На ней утвердили черновой вариант C++17 со множеством новых классов, методов и полезных нововведений языка.







Во время поездки мы обедали с Бьярне Страуструпом, катались в лифте с Гербом Саттером, жали руку Беману Дейвсу, выходили «подышать воздухом» с Винцентом Боте, обсуждали онлайн-игры с Гором Нишановым, были на приёме в мэрии Оулу и общались с мэром. А ещё мы вместе со всеми с 8:30 до 17:30 работали над новым стандартом C++, зачастую собираясь в 20:00 чтобы ещё четыре часика поработать и успеть добавить пару хороших вещей.



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



if constexpr (condition)



В C++17 появилась возможность на этапе компиляции выполнять if:



template 
auto rget(const std::pair& p) {
if constexpr (I == 0) {
return p.second;
} else {
return p.first;
}
}


При этом неактиваная ветка ветвления не влияет на определение возвращаемого значения. Другими словами, данный пример скомпилируется и:


  • при вызове rget<0>( std::pair{} ) тип возвращаемого значения будет short;

  • при вызове rget<1>( std::pair{} ) тип возвращаемого значения будет char*.



T& container::emplace_back(Args&&...)



Методы emplace_back(Args&&...) для sequence контейнеров теперь возвращают ссылку на созданый элемент:

// C++11
some_vector.emplace_back();
some_vector.back().do_something();

// C++17
some_vector.emplace_back().do_something();


std::variant



Позвольте представить: std::variant — union, который помнит что хранит.

std::variant v;
v = "Hello word";
assert(std::get(v) == "Hello word");
v = 17 * 42;
assert(std::get<0>(v) == 17 * 42);


Дизайн основан на boost::variant, но при этом убраны все известные недочёты последнего:




  • std::variant никогда не аллоцирует память для собственных нужд;

  • множество методов std::variant являются constexpr, так что его можно использовать в constexpr выражениях;

  • std::variant умеет делать emplace;

  • к хранимому значению можно обращаться по индексу или по типу — кому как больше нравится;

  • std::variant не нуждается в boost::static_visitor;

  • std::variant не умеет рекурсивно держать в себе себя (например функционал наподобие `boost::make_recursive_variant>::type` убран).



Многопоточные алгоритмы



Практически все алгоритмы из заголовочного файла были продублированы в виде версий, принимающих ExecutionPolicy. Теперь, например, можно выполнять алгоритмы многопоточно:

std::vector v;
v.reserve(100500 * 1024);
some_function_that_fills_vector(v);

// Многопоточная сортировка данных
std::sort(std::execution::par, v.begin(), v.end());


Осторожно: если внутри алгоритма, принимающего ExecutionPolicy, вы кидаете исключение и не ловите его, то программа завершится с вызовом std::terminate():

std::sort(std::execution::par, v.begin(), v.end(), [](auto left, auto right) {
if (left==right)
throw std::logic_error("Equal values are not expected"); // вызовет std::terminate()

return left < right;
});




Доступ к нодам контейнера



Давайте напишем многопоточную очередь с приоритетом. Класс очереди должен уметь потокобезопасно сохранять в себе множество значений с помощью метода push и потокобезопасно выдавать значения в определенном порядке с помощью метода pop():






// C++11
void push(std::multiset&& items) {
std::unique_lock lock(values_mutex_);
for (auto&& val : items) {
// аллоцирует память, может кидать исключения
values_.insert(val);
}

cond_.notify_one();
}

value_type pop() {
std::unique_lock lock(values_mutex_);
while (values_.empty()) {
cond_.wait(lock);
}

// аллоцирет память, может кидать исключения
value_type ret = *values_.begin();
// деаллоцирует память
values_.erase(values_.begin());

return ret;
}
// C++17
void push(std::multiset&& items) {
std::unique_lock lock(values_mutex_);

// не аллоцирует память, не кидает исключения.
// работает намного быстрее (см. #2)
values_.merge(std::move(items));

cond_.notify_one();
}

value_type pop() {
std::unique_lock lock(values_mutex_);
while (values_.empty()) {
cond_.wait(lock);
}

// не аллоцирет память и не кидает исключения (см. #2)
auto node = values_.extract(values_.begin());
lock.unlock();

// извлекаем значение из ноды multiset'а
return std::move(node.value());
}


В C++17 многие контейнеры обзавелись возможностью передавать свои внутренние структуры для хранения данных наружу, обмениваться ими друг с другом без дополнительных копирований и аллокаций. Именно это происходит в методе pop() в примере:

// Извлекаем из rbtree контейнера его 'ноду' (tree-node)
auto node = values_.extract(values_.begin());

// Теперь values_ не содрежит в себе первого элемента, этот элемент полностью переехал в node
// values_mutex_ синхронизирует доступ к values_. раз мы вынули из этого контейнера
// интересующую нас ноду, для дальнейшей работы с нодой нет необходимости держать блокировку.
lock.unlock();

// Наружу нам необходимо вернуть только элемент, а не всю ноду. Делаем std::move элемента из ноды.
return std::move(node.value());

// здесь вызовется деструктор для ноды


Таким образом наша многопоточная очередь в C++17 стала:


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

  • более безопасной — за счёт уменьшения количества мест, кидающих исключения, и за счет меньшего количества аллокаций;

  • менее требовательной к памяти.



Автоматическое определение шаблонных параметров для классов



В черновик C++17 добавили автоматическое определение шаблонных параметров для шаблонных классов. Это значит, что простые шаблонные классы, конструктор которых явно использует шаблонный параметр, теперь автоматически определяют свой тип:


















Было Стало
std::pair p(17, 42.0);
std::pair p(17, 42.0);
std::lock_guard lck(mut_);
std::lock_guard lck(mut_);
std::lock_guard lck(mut_);
auto lck = std::lock_guard(mut_);


std::string_view



Продолжаем эксурс в дивный мир C++17. Давайте посмотрим на следующую C++11 функцию, печатающую сообщение на экран:

// C++11
#include
void get_vendor_from_id(const std::string& id) { // аллоцирует память, если большой массив символов передан на вход вместо std::string
std::cout <<
id.substr(0, id.find_last_of(':')); // аллоцирует память при создании больших подстрок
}

// TODO: дописать get_vendor_from_id(const char* id) чтобы избавиться от динамической аллокации памяти


В C++17 можно написать лучше:

// C++17
#include
void get_vendor_from_id(std::string_view id) { // не аллоцирует память, работает с `const char*`, `char*`, `const std::string&` и т.д.
std::cout <<
id.substr(0, id.find_last_of(':')); // не аллоцирует память для подстрок
}


std::basic_string_view или std::string_view — это класс, не владеющий строкой, но хранящий указатель на начало строки и её размер. Класс пришел в стандарт из Boost, где он назывался boost::basic_string_ref или boost::string_ref.



std::string_view уже давно обосновался в черновиках C++17, однако именно на последнем собрании было решено исправить его взимодействие с std::string. Теперь файл может не подключать файл , за счет чего использование std::string_view становится более легковесным и компиляция программы происходит немного быстрее.



Рекомендации:


  • используйте единственную функцию, принимающую string_view, вместо перегруженных функций, принимающих const std::string&, const char* и т.д.;

  • передавайте string_view по копии (нет необходимости писать `const string_view& id`, достаточно просто `string_view id`).



Осторожно: string_view не гарантирует, что строчка, которая в нем хранится, оканчивается на символ '\0', так что не стоит использовать функции наподобие string_view::data() в местах, где необходимо передавать нуль-терминированные строчки.



if (init; condition)



Давайте рассмотрим следующий пример функции с критической секцией:

// C++11
void foo() {
// ...
{
std::lock_guard lock(m);
if (!container.empty()) {
// do something
}
}
// ...
}


Многим людям такая конструкция не нравилась, пустые скобки выглядят не очень красиво. Поэтому в C++17 решено было сделать всё красивее:

// C++17
void foo() {
// ...
if (std::lock_guard lock(m); !container.empty()) {
// do something
}
// ...
}


В приведенном выше примере переменная lock будет существовать до закрывающей фигурной скобки оператора if.



Structured bindings



std::set s;
// ...

auto [it, ok] = s.insert(42);
// Теперь it — интегратор на вставленный элемент; ok - bool переменная с результатом.
if (!ok) {
throw std::logic_error("42 is already in set");
}
s.insert(it, 43);
// ...


Structured bindings работает не только с std::pair или std::tuple, а с любыми структурами:

struct my_struct { std::string s; int i; };
my_struct my_function();
// ...

auto [str, integer] = my_function();


А ещё...



В C++17 так же есть:


  • синтаксис наподобие template struct my_class{ /*… */ };

  • filesystem — классы и функции для кросплатформенной работы с файловой системой;

  • std::to_chars/std::from_chars — методы для очень быстрых преобразований чисел в строки и строк в числа с использованием C локали;

  • std::has_unique_object_representations — type_trait, помогающий определять «уникальную-представимость» типа в бинарном виде;

  • new для типов с alignment большим, чем стандартный;

  • inline для переменных — если в разных единицах трансляции присутствует переменная с внешней линковкой с одним и тем же именем, то оставить и использовать только одну переменную (без inline будет ошибка линковки);

  • std::not_fn коректно работающий с operator() const&, operator() && и т.д.;

  • зафиксирован порядок выполнения некоторых операций. Например, если есть выражение, содержащее =, то сначала выполнится его правая часть, потом — левая;

  • гарантированный copy elision;

  • огромное количество математических функций;

  • std::string::data(), возвращающий неконстантый char* (УРА!);

  • constexpr для итераторов, std::array и вспомогательных функций (моя фишечка :);

  • явная пометка старья типа std::iterator, std::is_literal_type, std::allocator, std::get_temporary_buffer и т.д. как deprecated;

  • удаление функций, принимающих аллокаторы из std::function;

  • std::any — класс для хранения любых значений;

  • std::optional — класс, хранящий определенное значение, либо флаг, что значения нет;

  • fallthrough, nodiscard, maybe_unused;

  • constexpr лямбды;

  • лямбды с [this]( /*… */ ){ /*… */ };

  • полиморфные алокаторы — type-erased алокаторы, отличное решение, чтобы передавать свои алокаторы в чужие библиотеки;

  • lock_guard, работающий сразу со множеством мьютексов;

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





Напоследок



На конференции C++Siberia в августе мы постараемся рассказать о новинках С++ с большим количеством примеров, объяснить, почему именно такой дизайн был выбран, ответим на ваши вопросы и упомянем множество других мелочей, которые невозможно поместить в статью.



Расскажите о чём бы вам было интересно почитать
















































Проголосовало 11 человек. Воздержалось 3 человека.





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


Original source: habrahabr.ru.

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

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

«Веб — это самая сложная платформа в истории человечества» — интервью с Вадимом Макеевым из Opera

Понедельник, 11 Июля 2016 г. 16:33 (ссылка)





В этом выпуске «Без слайдов» гостем выступил Вадим Макеев aka pepelsbey, евангелист компании Opera Software, один из самых известных фронтенд-людей в стране, организатор многих мероприятий в индустрии.



Мы успели обсудить:


  • эволюцию WebKit;

  • путь Microsoft и новая модель браузера;

  • архитектуру современных браузеров;

  • как Opera выбирала между WebKit и Blink;

  • стандартизацию в вебе;

  • насколько трудна работа веб-разработчика;

  • JavaScript и его «продолжения»;

  • jQuery, и почему он все еще нужен;

  • HTTP/2;

  • ритм жизни евангелиста;

  • мобильный веб и Opera Mini;





Интервью взято в феврале, но руки дошли до публикации только сейчас.



Видео-версия нашей беседы вот тут:







А для тех, кто предпочитает читать, — под катом расшифровка нашей беседы.







Как все начиналось в двухтысячных



— Как у тебя началось погружение в веб? Сначала в твоей жизни появился фронтенд или Opera Software?



— Я хотел заниматься журналистикой. Потом неожиданно я узнал, что можно делать сайты, и начал заниматься фронтендом. А после, естественно, в моей жизни появилась Opera как браузер, которым я пользовался на Windows. В какой-то момент, когда я уже профессионально верстал и работал в Яндексе, ко мне пришли ребята из компании Opera и сказали, что им нужен опытный человек, который знает сообщество, умеет организовывать конференции, делать доклады и так далее. И я им очень подошёл.



— Ты в Opera с какого года?



— С мая 2009-го.



— До этого ты в индустрии сколько лет поварился?



— Мне повезло: я тогда работал в Москве и участвовал в организации первой конференции «Российские Интернет-технологии». Там впервые в России собралось очень много фронтендеров из Минска, Москвы, Санкт-Петербурга. Это было хорошее начало движухи.



— Сейчас ты сам очень многие вещи делаешь уже не как часть какой-то большой команды, а как глава своей конференционной команды.



— Да, мне повезло делать первый РИТ и делать первый Яндекс.Субботник. Я помню, как мы сидели в кабинете, придумывали название — всё это было интересно. Как только Я.Субботники закрутились, я ушёл из Яндекса, и в конце того года мы сделали первую конференцию Web Standard Days в Минске. Собственно, это было начало большой бесплатной конференции, которую мы делаем несколько раз в год.



— Сейчас ты активно сотрудничаешь с Олегом Буниным: это фронтенд-секции на РИТ++ и на HighLoad++?



— Да, когда мы собрались в первый раз в 2007-ом году, Олег сказал: «Сделай какой-нибудь фронтенд». Я прочитал собственный доклад, пригласил знакомых людей. И каждый год весной мы снова-снова собираемся, и это раньше называлось РИТ, потом РИТ++. Сейчас фронтенд на РИТ++ выделился в большую двухпоточную конференцию на два дня — в прошлом году было порядка тридцати докладов. В общем, пытаемся не просто бесплатную конференцию по разным городам делать, но и большую платную в Москве.



— Понятно. А твой интерес к журналистике с чего начался?



— Как-то так получилось. Я попал в городскую газету «Пять углов», сто лет назад она была в издательстве «Шанс». Мне было интересно заниматься карикатурой.



— Так ты художник?



— Я когда-то баловался, рисовал. Потом это всё пошло: комментарии, тексты, ещё что-то такое… Наверное, это не сильно связано с образованием. Я помню, как я искал первые материалы на английском или на русском языке для того, чтобы узнать как работает веб, как работает JavaScript, как нужно одну версию написать для Netscape, а другую — для Internet Explorer. В общем, я старичок уже.



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



Про стандарты



— А почему именно веб-стандарты? Это просто название, или тебя тема стандартов особенно интересует?



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



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



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



— Получается, что сейчас это уже просто дань истории?



— Сегодня веб-стандарты победили. И мы, как сообщество, радостно продолжаем нести этот флаг.



— В двухтысячных была проблема — каждый браузер делал всё по-своему.



— Да, и разработчики тоже все по-своему делали, чтобы работало одновременно в нескольких браузерах.



— Последние 10–15 лет шёл процесс стандартизации. Сейчас веб стандартизован?



— Сам термин «веб-стандарты» появился из знаменитой программной книги Джеффри Зельдмана «Designing with Web Standards», на обложке которой есть его фото в синей шапочке. И все отмечают день веб-стандартов Blue Beanie Day — «День синей шапочки», по-моему, в середине апреля. Все на аватарку себе синюю шапочку ставят.



image



Был сайт A List Apart — он, собственно, до сих пор и есть, — с которого все эти идеи распространились, а мы их подхватили. Webmascon переводил очень много с A List Apart.



— Webmascon — что это за сайт?



— Его делал Александр Качанов. Это, в основном, был переводной ресурс: Нильсен, Зельдман, просто алестапартовские статьи — в общем, самые важные вещи. Потом в этой команде появился Макс Россомахин. Сайт был эдакой концентрацией фронтенда на русском языке. И вокруг этого всё наше сообщество и образовалось — оттуда мы все идём. А зельдмановская идея веб-стандартов, по-моему, изменила веб в лучшую сторону.



— В современном мире все говорят про коммьюнити, про опенсорс, но везде, как правило, рулят крупные компании. Мы прекрасно понимаем, какие корпорации стоят за браузерами Safari, Internet Explorer, Chrome. Разве что с Mozilla чуть-чуть по-другому и, наверное, с Opera. Как так вышло, что гиганты смогли между собой о чём-то договориться?



— Оказалось, что если стандартами не заниматься и браузеры не развивать, то веб начинает загибаться. Был период, когда Internet Explorer 6 занял 90% рынка, потому что это был очень крутой браузер и всем остальным было очень сложно с ним конкурировать. Тогда агонизировал Netscape. И ничего нового интересного на горизонте не было.



Была Opera с маленькой долей, и был Firefox. Они все были не очень совместимы друг с другом по многим вещам. Начал появляться Flash, люди всерьёз начали делать на нем сайты. Разработчикам, которым нужно публиковать свой контент в веб, веба было недостаточно. Начали появляться альтернативные форматы.



В этот момент другие браузеры начали подтачивать долю Internet Explorer, и она упала до 40%, а потом и ещё ниже. Это были Opera, Firefox, Safari (дефолтный браузер на Apple, и вместе с Apple он начал расти). Потом и Chrome появился.



И получилось, что гораздо удобнее взаимодействовать на единой платформе. Почему так? Не знаю. У типичного языка программирования — у C++, у Java, у Perl, у Python — есть чёткая документация, и одна-две классических реализации того, что они делают. В софтверной области совместимость довольно легко контролируется.



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



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



Про историю развития браузеров и эволюцию WebKit



— А насколько сильно на всю картину повлияла история, когда Google пришёл в WebKit?



— Google с самого начала очень помог проекту WebKit развиться, но настолько увлёкся, что ему стало тесно, и он сделал форк — свой движок Blink. Это действительно очень сильно поддержало альтернативные браузеры, потому что тогда было ощущение, что все разработчики пользуются только Firefox, все тестируют в Firefox, это в мире был главный браузер в 2006-2008 годы. Было ощущение, что Firefox победил.



— Но Chrome же, по-моему, начался массово году только в 2009-ом?



— Да, он начал довольно поздно, но очень мощно.



И я помню, с какими бешеными глазами я читал новость о том, что Apple выпустила Safari для Windows. До этого платформы WebKit на Windows не было в принципе, она была Mac-only. Так что это был первый WebKit на Windows, который в принципе можно было запустить. А сейчас браузеры для Windows — практически все на WebKit-е: Chrome, Opera, Яндекс.Браузер.



— Первый порт сделал сам Apple, а потом уже пошёл Google и добил?



— Да. И первый эппловский порт был довольно кривой. Но кстати и Chrome, впервые портированный на Windows, тоже был не очень хорош. Потому что были какие-то завязки внутри WebKit, которые мешали cделать такой порт нормально.



Как начинался Google и почему он победил? Реклама! Поиск! Поиск и реклама. Удобная.



Сама компания взяла в руки браузерный движок и сделала то, что ей нравится. И не просто для того, чтобы рекламу лучше показывать, а всерьёз вложилась в отрасль. То, что делает Google, помогло перезапустить наш браузер на новом движке, который гораздо легче и удобнее, чем был WebKit в том состоянии, когда Google ещё не пришёл туда. Тот приход стал очень знаковым шагом.



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



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



— Я бы не сказал, что он категорически монополизирован. У Firefox ещё позиции есть. Очень сильная заявка от Microsoft Edge.







Путь Microsoft и новая модель браузера



— А у Edge не новый движок?



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



Microsoft, прежде всего, — это корпоративный гигант. У него очень много клиентов и очень много денег к нему приходит из корпоративного сегмента. Соответственно, выпустить новую версию браузера, в которой не работает вообще вся эта корпоративная структура, какие-нибудь внутренние сети, для них невозможно. Поэтому они, начиная с Internet Explorer 6, тянули за собой для совместимости все движки. В IЕ11 были все движки вообще предыдущие, и их можно было переключать в зависимости от doctype, со всякими HTTP header-ами и метазаголовками.



— То есть, можно написать в своем коде некую инструкцию о том, какой там движок?



— Да. Допустим, у тебя сайт заточен под IE9 и в нём работает идеально. А тут выходит IЕ11, и на сайте в нём что-то ломается. Ты добавляешь специальный заголовок, который переключает браузер в режим IЕ9, и всё работает идеально. Это безумно совместимо, ультра-совместимо. Но это мешало развивать браузер.



— Я очень давно занимаюсь платформой Java, и поэтому знаю, что необходимость поддерживать сильную совместимость очень сильно тормозит развитие.



— Именно. Поэтому я считаю, что ребята из Microsoft сделали сильное, смелое движение. Мы привыкли за последние несколько лет, что браузеры становятся вечнозелёными. Они обновляются не когда приходит апдейт Windows, который ты не ставишь, потому что она у тебя взломана, а когда браузер сам решит обновиться. А это происходит раз в месяц. Эту модель быстрых обновлений впервые показал нам Chrome. Потом Firefox. И версии начали увеличиваться с бешеной скоростью. Собственно, мы тоже выпустили браузер с такой системой апдейтов.



Насколько я понимаю, Edge отбросил обратную совместимость для того, чтобы стать легче, быстрее работать и для того, чтобы обновляться чаще. И они действительно обновляются довольно часто, с каждым маленьким обновлением Windows.



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



Про архитектуру современного браузера



— А из каких кусков состоит современный Webkit-based браузер? Яндекс, Opera, Chrome, Safari — все они разбиты архитектурно на одни и те же куски? Можешь рассказать, что это за куски, как они друг с другом взаимодействуют?



— С самого начала ребята, которые делали KDE, сделали свой браузерный движок, который умел делать рендринг HTML, CSS и JavaScript отдельно. Apple форкнула эту штуку и начала делать WebKit.



Там было два главных компонента: тот, что обрабатывает CSS с HTML, и тот, который работает с JavaScript. Соответственно, это разделение на вёрстку и JavaScript до сих пор является основным в мире браузеров, которые пошли от Webkit-а. Есть какая-то вёрсточная основа, а есть JavaScript-движок, собственный у каждой из компаний.



Когда ребята из Apple и Google делали общий движок WebKit, у них был общий движок для JavaScript и для вёрстки, а потом Google написала собственный JS-движок V8, который, кстати, сейчас использует и Node.js.



Соответственно, движок HTML и CSS у Safari, Chrome и у других браузеров на Webkit и Blink — общий. А вот JavaScript-движок у каждого собственный. У Safari был движок Nitro, у Google — V8, у нас был собственный движок в Opera — Carakan. У Edge свой собственный скриптовый движок Chakra, который они заопенсорсили.



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



Это всё позволяет довольно быстро сделать свой браузер, потому что всё это — Open Source: есть проект Chromium, в который не включены некоторые вещи, которые включены в Chrome, потому что они принадлежат Google и, допустим, запатентованы как-то особенно. Можно быстренько скачать несколько гигабайт Chromium себе, форкнуться и сделать себе браузер – Opera, Яндекс.Браузер, Амиго, что-то ещё. То же самое можно сделать и в случае мобильного браузера. Есть очень много мобильных Chromium-ов на Android и на других платформах, которые несут в себе гугловскую основу-движок и рисуют собственный интерфейс поверх.



— В Chromium основной контрибьютор — тоже Google?



— Да, Google — основной контрибьютор. Но там есть еще Intel, Samsung, Opera, Яндекс.



— Понятно, что Intel занимается тем, что, например, в JavaScript-движок интринсики вставляет и другие процессорные оптимизации. А остальные?



— Разные интересы бывают. У Intel, у Dell и у разных других компаний свои интересы по развитию веба. У них есть собственные продукты и платформы.



На самом деле, удивительные вещи происходят, когда Microsoft контрибьютит в Chrome реализацию своей спецификации pointer-events, которую поддерживают её браузеры, чтобы достичь общей совместимости.



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



Как Opera выбирала между Webkit и Blink



— Когда Opera выбирала между WebKit и Blink, как вы делали выбор?



— На самом деле, это не был выбор как таковой.



Сначала мы перешли на WebKit. Приняли решение где-то в конце 2012 года, а в начале 2013 года этот переход анонсировали. Поэтому мой доклад той поры называется: «Зачем Oper-е WebKit».



Но сразу после этого, где-то в январе-феврале 2013 года, Google форкает WebKit. Первые полгода особой разницы между Webkit-ом и его форком Blink, на самом деле, не было — это были просто два разных репозитория. В Blink происходили структурные изменения, какие-то вещи отбрасывались, какие-то появлялись, но в самом начале разница была не очень большая. Кроме того, что JavaScript-движок у Google уже давно был свой.



Мы в то время сильно вложились не в Blink или WebKit, а именно в проект Chromium: Opera сделана не просто на Blink, а именно на Chromium, и мы контрибьютим и в инфраструктурные решения, а не только в рендеринг и прочие дела. Поскольку Chromium сделан на Blink, то мы пошли за ним, а не стали оставаться на WebKit.



— С того момента прошло больше трех лет. Если посмотреть на то, как сейчас развиваются WebKit и Blink, то можешь как-то коротко охарактеризовать отличия?



— Apple начинает походить на Microsoft в том смысле, что им нужно сохранять совместимость, потому что WebKit — это встроенный движок, на котором работают компоненты Mac OS. Из-за этого получается, что им нужно сохранять совместимость: всякие мессенджеры и другие программы, встроенные в Mac OS, насколько я понимаю, работают на WebKit-е.



— И iTunes, видимо, работает на встроенном WebKitе.



— Да, и App Store, и прочие приложения. Не уверен, что им прямо так уж сильно нужно сохранять совместимость. Возможно, у них другая политика в этом смысле, но с самого начала идея форкнуть WebKit в Blink была связана с тем, что темпы и стиль разработки Google — другие, и им было тесно в этом смысле. Соответственно, сейчас Google гораздо смелее внедряет новые вещи, а у Safari цикл выхода — год. Вместе с новой операционной системой Apple показывают новый движок для Safari.



Совсем недавно (интервью взято в феврале 2016 года — прим. авт.) Apple выпустили бету, в которой появились новые фичи. Это было событие, потому что эта бета должна выйти, по идее, раньше релизного цикла. То есть, появилась скорость, отброшенные CSS-префиксы, новые внедрённые фичи. Google гораздо смелее отбрасывает CSS-префиксы, удаляет свойства и в целом развивается гораздо быстрее.



— Это шаги в сторону стандартизации?



— Да. И сейчас браузеры уходят от браузерных префиксов. Если в стабильном Chrome зайти в настройки и включить экспериментальный режим, то в браузере проявятся новые фичи, которые пока закрыты для общественности. В Safari такого сделать нельзя.



В Safari есть специальные сборки, которые нужно скачивать и проверять. А Google прямо в стабильную версию внедряет все штуки, но просто их выключает по умолчанию, чтобы пользователи не наломали дров. Это делает все эти новые фичи ближе к разработчикам. Они включаются одним флагом — «включить экспериментальные фичи». И у тебя в браузере появляется сразу всё, над чем Google в данный момент работает.



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



Apple до сих пор придумывает некоторые вещи на лету: «А почему бы нам не сделать классные иконки для вкладочек?» А в спецификации в W3C про это ничего нет. Так что они придумали, сделали и задокументировали мимо W3C.



Или: «Мы придумали, как веб-приложение устанавливать на рабочий стол вашего iPhone». Нет спецификации нормальной, только немного документации на сайте.



Apple сейчас немного напоминает Microsoft времён IЕ6. Все не настолько плохо — Apple, конечно, много занимается стандартизацией и разработкой. Но некоторые черты есть, поэтому немного грустно на это смотреть.



Про то, как происходит стандартизация в веб и про то, почему это самая сложная технология человечества



— А как вообще происходит стандартизация какой-то большой фичи для веба?



— Есть два пути, по которым сейчас всё происходит.



Первый путь — старинный. Когда писались все основы текущего веба — HTML, CSS и прочие, — они писались на бумаге. Печатались на печатной машинке или на компьютере. Их сначала придумывали, а потом говорили разработчикам браузеров: «Это должно работать так, реализуйте».



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



И есть второй путь. Он поначалу был очень плохой идеей и приносил плохие вещи, а сейчас он становится интереснее и лучше. Это путь, когда внутри браузера или внутри компании появляется какая-то задача, и они решают её способом браузера. Допустим, pointer-events со спецификацией, которые родились в Microsoft. Ребятам понадобился Grid Layout, чтобы сделать плитки для Windows 8 — интерфейс Metro. А pointer-events понадобилась потому, что они сделали touch-устройства — свои первые Microsoft Surface, — и начали двигаться в touch-рынок.



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



Это хороший путь — они показали, внедрили и ещё помогли сделать реализацию для других браузеров, в том числе, для Firefox. Они уже даже уломали Chrome — правда, разработчики согласились не сразу.



Cейчас есть альтернативные реализации Grid Layout в Firefox и в Safari и Chrome, а изначально всё это появилось в IЕ10.



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



— Если коротко, то раньше основными были спецификации HTML и CSS, и разработчики старались упихнуть вообще все в какую-то из них. В HTML-спеку — структура, какие-то API, связанные с HTML, и так далее. В CSS тоже: CSS1 — это набор одних фич, CSS2 — набор других.



Потом начал появляться CSS3, и люди поняли, что это всё – ерунда, и сейчас таких вещей, как CSS3 и HTML5, формально не существует. Есть просто спецификации HTML и CSS, и у каждой из них есть модули, а у модулей — версии.



Тот же самый Grid Layout сейчас называется «Grid Layout level1». Раньше было CSS colors level 3. И люди говорили: «Ну, это CSS3-цвета». А на самом деле это «CSS, третий подход к решению проблемы».



Сейчас есть Grid Layout level1. Это просто CSS и Grid Layout версии 1. Когда понадобятся новые фичи, скорей всего они войдут уже в level 2, level 3 и так далее. То есть, у каждого модуля есть своя версионность.



— Модулей много?



— Модулей довольно много — их десятки. На разные темы: flexbox, гриды, цвета, блоки, поведение флоутов. И что интересно — если раньше писали отдельные модули, и разработчикам браузеров приходилось реально понимать, как эти модули друг с другом взаимодействуют, то сейчас начали писать интеграционные модули. То есть, берут и связывают разные спецификации вместе и пишут третью, которая их дружит вместе. И в итоге реализация появляется гораздо интереснее. Например, если раньше float можно было использовать для смещения картинки налево так, чтобы текст её обтекал, то сейчас

есть такие вещи как float top, float bottom. И для этого пишут отдельную спецификацию, описывают её взаимодействие с другими элементами. Сейчас происходит много интеграционной работы между спецификациями CSS и HTML.



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



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



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



Про то, насколько трудна работа веб-разработчика



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



— Веб до сих пор остаётся платформой, под которую довольно легко начать. Чтобы программировать под iPhone, выпустить приложение в App Store, тебе нужно купить Mac, тебе нужно купить iPhone, тебе нужно платить за Apple-овскую подписку сто баксов в год. А ещё нужно образование, чтобы вообще понимать парадигмы программирования, паттерны, выучить язык и так далее…



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



— Является ли низкий порог входа тем фактором, который дает вебу двигать всю индустрию?



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



— HTML сейчас во многих школах проходят в десятом классе…



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



Вторая важная причина — всё это никому не принадлежит. Например, Flash, о котором все говорили, что это «будущее веба», принадлежал долгое время Macromedia, потом Adobe. Соответственно, им же принадлежат патенты. Никакая крупная компания не будет вкладываться в то, что принадлежит другой компании, чтобы не оказаться в узких рамках патентных сложностей или каких-то ежегодных платежей.



Сейчас это наше общее достояние — веб и веб-технологии. Конечно, приходят люди и говорят: «Нам веб не нравится. Веб сложный, много движков, давайте мы напишем крутую софтверную платформу на каком-нибудь Swift». Новая интерфейсная софтверная платформа, новый язык, классный, опенсорсный даже. И это делает его гораздо интереснее.



Objective-C, на котором все раньше писали под Mac OS и iOS, принадлежит Apple. И многие вендоры не хотели связываться с технологией, которая находится целиком в руках другой компании.



— Откровенно говоря, язычок так себе. Он сложный, старый, C-подобный, родом из шестидесятых годов…



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



Про JavaScript, его плюсы, минусы и «продолжения»



— Но мы же понимаем, что есть ещё JavaScript, который совсем не декларативный. И основное, за что сейчас критикуют веб, это тоже JavaScript. Потому что движки разные, и с ними очень много проблем. И с самим языком есть большие проблемы. Как так вышло, что этот довольно странный и древний по синтаксису язык победил?



— Он никому не принадлежит и работает в каждой кофеварке. Браузер есть практически везде. Чтобы запустить код, написанный на С, его ещё нужно скомпилировать под несколько платформ, а JavaScript — сразу работает в браузере.



Джависты и прочие люди, приходящие в JavaScript, говорят: «Ужасный язык, в нем все не так, как мы привыкли». А если ты с самого начала пишешь в вебе — тебе, в общем-то, не жмёт.



— То есть, это просто искажение восприятия?



— Да. Это просто деформация людей, которые привыкли работать с одним, а теперь работают с другим. Естественно, это всё приводит к появлению новых языков — JavaScript типизируют с помощью TypeScript и т.п.



— Когда я последний раз заказывал разработку сайта, мне разработчик сказал: «Слушай, только я буду верстать не под текущую версию JavaScript, а под следующую версию стандарта, которая ещё не реализована в браузерах». Я так понимаю, что у JavaScript есть какая-то версионность, он сам является некоторым диалектом? Можешь про это подробнее рассказать?



— Есть спецификация ECMAScript. Есть ECMA-сообщество, которое и разрабатывает JavaScript. Долгое время там ничего не происходило, и разработчики начали придумывать, фантазировать собственные реализации языка следующим образом: мы пишем на некотором довольно безумном языке, с какими-то собачками, угловыми скобочками и другими штучками, а это всё компилируется в ECMAScript 5 — в тот JavaScript, который работает везде. Этот синтаксический сахар назывался CoffeeScript. Без угловых скобочек, с отступами, с безумными конструкциями, которые упрощали написание языка и реализовывали с помощью синтаксической трансформации те вещи, которые были неудобны…



— Транслировать язык — довольно тяжёлая задача.



— Они похожи в базовых принципах. И очень многое из CoffeeScript пришло в следующую версию ECMAScript, JavaScript в браузерах. Долгое время в старых браузерах у нас был ECMAScript, потом ECMAScript 5 в современных браузерах, а сейчас ECMAScript 6 уже реализован в браузерах процентов на 90. Оставшиеся 10%, которые так уж хочется некоторым разработчикам, тоже можно использовать. То есть, можно писать код прямо по спецификации ECMAScript 6, или ECMAScript-2015, как она теперь называется, а потом включить маленький транслятор, который сделает из этого кода работающий везде код на ECMAScript 5.



Сейчас, если язык развивается медленнее, чем нужно каким-то разработчикам, эти разработчики придумывают собственную версию языка и делают транслятор для него. Это справедливо для CSS — всякие Sass, и Less, и Stylus, и PostCSS, в частности.



Это справедливо для JavaScript, но было трендово и модно несколько лет назад. А сейчас всё больше людей предпочитают писать на чистом JavaScript без всякого безумия и транслировать только совсем мелкие фичи.







Про jQuery, и почему он до сих пор нужен



— 10 лет назад начался AJAX. Из него вырос jQuery и всё остальное. Сейчас найти вокруг людей, которые серьёзно пишут на jQuery — сложная задача.



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



Вокруг этой всей синтаксической упрощёнки начало появляться море плагинов. Вещей, реализующих выбор даты в выпадающем окошке, слайд-шоу и так далее. Разработчику, чтобы нафигачить сайт, нужно совсем немного — скачать Bootstrap, подключить jQuery-плагин, поменять тему, вставить картиночки — и готово! Эта индустрия быстрых сайтов под простые задачи — она до сих пор на фрилансе, и даже у больших контор, которые занимаются разработкой, она вовсю ещё распространена. Поэтому jQuery никуда не уходит. И это действительно вещь, которой стоит пользоваться, когда у тебя простые задачи, и ты хочешь сделать всё максимально быстро.



В ответ на меняющуюся реальность вокруг, когда уже не нужно писать несколько веток работающего во всех браузерах кода, jQuery сам начал развиваться иначе. Сейчас откидывается обратная совместимость всё больше и больше, в jQuery меньше всяких polyfill-ов и прочей фигни, больше используются встроенные браузерные методы. jQuery 2 отбросил одну совместимось, jQuery 3 практически отбросит другую, не будет заниматься кросс-браузерностью, а будет просто реализовывать интересные синтаксические вещи, такие как: спрятать элемент, переключить классы и так далее.



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



Microsoft написал себе когда-то XMLHttpRequest, которые начали называть AJAX. А потом вышла спецификация XHR2. А потом это стало настолько неудобно, что отбросили всё это к чёрту и написали отдельную спеку fetch, которую сейчас все браузеры реализуют, в ней есть polyfill и так далее. Всё очень быстро развивается, и тот же самый jQuery то ли будет, то ли уже использует тот самый fetch, если он понимает, что тот есть в данном браузере. Потому что fetch работает быстрее и удобнее.



Про концепцию одностраничного веба и ее ограничения



— Следующая история, которая мне интересна, это одностраничный веб. Это хорошее дизайнерское решение с точки зрения юзабилити? Или это ограничение конкретных фреймворков?



— Речь про SPA (Single Page Application). Идея пришла, мне кажется, из всяких админок, из всяких сложных интерфейсов, где перезагружать всю страницу и терять контекст происходящего — проблема: у тебя есть двадцать восемь форм, ты переходишь на другую страницу, и тебе нужно сохранять состояние формы — это всё очень сложно.



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



— У меня ощущение, что это попытка реализовать на вебе десктопную логику.



— Есть такое ощущение. Есть сложный давний спор о клиентском рендеринге — с самого начала на странице нет ничего, потом приходят данные, и на клиенте JavaScript-ом начинает рисоваться весь HTML против того, что HTML приходит с сервера. Это всё до сих пор открытая дискуссия.



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



— При клиентском рендеринге вся логика отрисовки ложится на клиента. А значит, клиент должен быть тяжелее, процессор мощнее и т.п.



— Эта дискуссия до сих пор открыта. У меня нет ощущения, что кто-то из оппонентов выиграл. Представим, что в случае клиентского рендеринга на сервере побился один символ в JavaScript — сайт не будет работать вообще! У пользователя будет белая страница, а в консоли много красного. Недавно у твиттера было такое, потому что у них что-то побилось. А если на странице всего лишь не загрузился какой-то JavaScript, в принципе ей можно пользоваться.



— Выходит, это вопрос надёжности.



— Вопрос надёжности здесь встаёт остро. Поэтому я сторонник такой идеи — нужно отдавать браузеру HTML, а потом улучшать этот HTML JavaScript-ом настолько, чтобы он работал удобнее. Такой компромиссно-гибридный вариант.



Ember.js и AngularJS умеют это делать следующим образом: они рендерят на сервере свой HTML, отправляют его браузеру, а потом уже на основе этого его улучшают дополнительным подгружаемым JavaScript. Получается так называемое «универсальное приложение».







Про HTTP, HTTPS и HTTP/2



— Мы говорим про довольно высокоуровневые слои. Давай спустимся ниже и поговорим про HTTP и HTTP/2. Что сейчас с ними происходит?



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



— По спецификации HTML браузер может делать две коннекции к каждому URL-у, а в реальности браузеры делают по 6, по 10, по 20. Это очень забавно.



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



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



— Он гугловый?



— Его делал не только Google, там и другие ребята участвовали. Были SPDY-модули для Nginx, для Apache, чтобы всё это нормально работало. В итоге все эти идеи из SPDY перешли в HTTP/2. И у нас появился протокол для передачи данных, который был разработан не за дверями университета на бумаге, а который реально реализует потребность современного веба. Меньше служебной информации, больше данных; пакеты можно склеивать, можно поддерживать постоянное соединение и так далее.



— Например, компрессия хэдеров.



— Да-да. Очень много всего, что работает гораздо эффективнее, но есть ограничение, что все эти вещи работают только секьюрно, только через HTTPS. Приход HTTP/2 очень сильно меняет фронтенд, потому что все техники, которые мы за эти годы узнали и приняли в свое вооружение, становятся больше не нужны. И нам приходится сейчас осознавать, что всё, что мы считаем хорошим, — оно на самом деле, если не вредит, то, по крайней мере, бесполезно.



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



Тот же CoffeeScript. Сначала разработчики быстро придумывают что-то, говорят: «Нам нужно это», а потом разработчик спецификации протоколов и всего остального думает: «А, вот это разработчикам нужно», и реализовывает это более правильно, эффективно, совместимо со всеми остальными стандартами.



— Как я понял, сейчас все браузеры уже поддерживают эту спецификацию?



— Да, браузеры начинают поддерживать HTTP/2.



— Сейчас имеет смысл переводить свои сайты на HTTP/2?



— Мне кажется, что об этом точно нужно знать и это нужно пробовать. Конкретно сейчас я бы рекомендовал всем переводить свои сайты сначала на HTTPS, дать задание админам, чтобы они, как минимум, расследовали и поняли, какова стоимость всех этих сертификатов. Есть бесплатные сертификаты, которые нужно обновлять раз в 90 дней.



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



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



Всё ещё пока не совсем так: не все хостинги умеют, не все админы врубаются, как это делать. Считается, что тот же самый Let's Encrypt уже вышел из беты, но в реальности в нем всё ещё до конца не отлажено. Но я всё-таки рекомендую всем переходить на HTTPS, потому что и данные нужно защищать, а браузерное API терять не стоит. Ну, а после перехода на HTTPS сможете заняться и переходом на HTTP/2.



— А что это означает для разработчика?



— Нужно сделать так, чтобы сервера отдавали всё правильно. И это совсем админская заумь для меня — как поднять у себя этот HTTP/2. Это немножко другая история. Я больше знаю о том, что нужно сделать на клиенте, чтобы не делать лишних вещей.



— Собственно, как изменится клиентская разработка? Я, например, понял, что HTTP/2 — это крутая штука. Что дальше? Что я, как разработчик, должен сделать со своим сайтом?



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



— А как браузер поймёт, что теперь протокол другой?



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



— Условно говоря, браузер просто получает заголовок, что сервер поддерживает HTTP/2...



— … и начинает по-другому работать с сервером. Я не буду сейчас прямо расписывать всякие нюансы, но сейчас есть пяток хороших докладов с разных конференций конца прошлого года, которые рассказывают про HTTP/2.



В новостях «Веб-стандартов» раз в месяц появляются две-три ссылки про HTTP/2. Люди всерьез начинают этим заниматься. Но думать про HTTP/2 и про все эти оптимизации, пока у вас нет HTTPS, смысла нет…



— Но в браузерах это всё уже есть? И можно уже получать профит от этого?



— Плюс-минус всё есть. Полная поддержка — это вопрос, думаю, этого года. Пока это всё ещё сырое, чтобы прямо совсем стартовать и идти. Надо изучить. Тот же Виталий Фридман из Smashing Magazine рассказывал о том, что они перевели сайт на HTTPS, включили HTTP 2, и стало медленнее. И начали разбираться, что не так пошло. Посмотрели–посмотрели и поняли, что, это не стопроцентно очевидная вещь, которая прямо сразу всё сделает хорошо. Нужно настроить, нужно врубиться и так далее. Там слишком много админской магии для меня и для типичного разработчика.



— Кажется, что HTTP быстрее, потому что не нужно заморачиваться с кучей вещей. Анатоликс, — раньше он работал в Яндексе, — рассказывал об этом на последнем Highload: типичный антивирус сканирует HTTP-трафик, но не сканирует HTTPS. В итоге (внезапно) для клиента HTTP работает дольше, чем HTTPS.



— Да, и он показывал эти графики. Интересный был доклад. Но есть и другие проблемы: ты в московском метро к вайфаю подключился, и если у тебя не HTTPS, то провайдер начинает показывать тебе всякие баннеры или встраивают на страницы какие-нибудь штучки. Так что, быстро не будет. А ещё Билайн там у себя вставлял какие-то баннеры в трафик людям.



— В общем, если вы не хотите, чтобы на вашем сайте появилась всякая ерунда от отельного вайфая, от Билайна, московского метро и прочих чуваков — делайте на свойем сайте HTTPS. Правда, к вам может прийти Роскомнадзор — но это тема для другой беседы.



Про ритм жизни евангелиста



— Евангелизм для тебя — это выступления на мероприятиях, статьи, коммьюнити, конференции?



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

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



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



С другой стороны, есть особенность моей команды в Opera Software: она вся распределённая — сейчас в команде пять человек. Мы все съезжаемся несколько раз в году в центральный офис или куда-нибудь ещё. Скоро мы снова съезжаемся, чтобы синхронизироваться, пообщаться и спланировать, что мы будем делать.



— Основные направления того, что ты рассказываешь? Сейчас, например, мы много говорим про стандарты, мало говорим про Opera, про Opera Software. Почему так получается? Как стыкуются твои интересы с бизнесом Opera?



— Когда меня позвали на собеседование в Осло в 2009-ом году, мне задали вопрос: «Вообще чем бы ты хотел заниматься? Что тебе интересно?». Я рассказал, естественно, о себе, мне рассказали про компанию. И я спросил, чем мне в итоге придётся заниматься. На сколько продавать Opera и на сколько процентов рассказывать про веб-стандарты. Мне сказали, что, грубо говоря, веб-стандарты — 70%, продавать Opera — 30%.



На самом деле, мне не наврали, потому что, рассказывая про веб-стандарты, рассказывая про веб, про технологии, и вообще являясь экспертом в этой области, ты становишься заметным. Тебя знают, тебя слышат. И соответственно, если у людей возникает какой-то вопрос или проблема с Opera — они вспоминают: «ага, Макеев на конференции выступал. Вот он же там работает. Обратимся-ка к нему.»



Скажи мне, что ты будешь делать, если у тебя что-то не так в Firefox? Если что-то не так в Safari? Наверное, напишешь им в трекер. А тут можно встретиться, поговорить со мной, можно мне написать письмо или связаться другими способами.



— В твиттер. Даже в два твиттера, как мы вчера с тобой выяснили.



— Два твиттера — англоязычный и русскоязычный. Надо ещё на китайском завести. Шутка.



— Ну, это тяжёлая история. Проще будет нанять там евангелиста.



— Типа того. У нас, кстати, был Зи Бин из Китая. Тогда у нас команда была 13 человек, и люди были и в Латинской Америке, и в Азии. Когда мы перешли на новый движок, совместимость стала лучше, и в итоге меньше людей нужно для того, чтобы решать проблемы. Как результат — моя нагрузка выросла, и я теперь больше путешествую.



— Это Россия, Европа, в основном?



— Не только. Я два года подряд уже езжу на Chrome Dev Summit — очень интересное мероприятие в Калифорнии. Проходит в офисе Google. Поскольку там Chrome лидирует во многих направлениях, у них очень интересные доклады. И они всё это транслируют и тут же выкладывают записи. Поэтому, если вы ещё не смотрели записи с Chrome Dev Summit — очень рекомендую, потому что там происходят самые новые вещи.



Про мобильный веб и Opera Mini



— Года два назад говорили, что победил мобильный трафик, трафик с мобильных устройств: это и мобильный браузер, и приложения. Как в связи с этим, на твой взгляд, вообще меняется веб? Как в связи с этим должен переориентироваться веб-разработчик?



— Есть большая проблема. Разработчику ближе то, на чём он разрабатывает. Современный разработчик не будет разрабатывать на мобилке, которая у него в кармане — там это делать просто неудобно. Он разрабатывает на десктопе. Поэтому сайты, которые разрабатывает разработчик, лучше всего работают на десктопе, так как там есть инструменты отладки и всё остальное. В мобильных браузерах начали появляться удобные инструменты отладки, потому можно подключиться какому-нибудь Android по USB и начать удобную отладку, тут же смотреть на десктоп и отлаживать в телефоне, но для этого нужны устройства. Хорошо, если у тебя в кармане телефон для целевой платформы, а если у тебя какая-нибудь Nokia с кнопочками — сложновато. Нужно получать доступ к каким-то фабрикам с устройствами и так далее.



— Раньше ставили кучу виртуальных машин…



— И до сих пор, чтобы тестировать в IE или в Edge, нужно иметь виртуалку. Хотя стало проще — ставишь какой-нибудь бесплатный Virtual Desktop. И Internet Explorer начал выкладывать бесплатные виртуальные машины, удобные, с нужными версиями. Ты их скачиваешь тут же.



— «Microsoft думает о вас.»



— Да, в смысле тестирования они очень сильно помогли.



Есть такая тенденция, что разработчики больше заботятся о десктопе, хотя уже не стОит. И разработчики браузеров стараются им в этом помогать. Допустим, на Chrome Dev Summit в прошлом году в ноябре анонсировали новый отладчик для Chrome, для браузеров на основе Chromium, который сразу же показывает адаптированную версию. Если раньше вы открывали панель отладки в Chrome, и он вам показывал обычную страничку и панельку снизу, то сейчас он автоматически открывает адаптированную версию. Открывает окно, которое можно поресайзить, где можно выбрать модель телефона — он сам сделает zoom, scale и так далее. Разработчики браузеров стараются решать проблемы. Но всё равно, если у современного разработчика Android, iOS на столе, скорее всего, он уже отстаёт.



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



— У меня дома 4 телефона, 3 планшета, ещё что-то. Специфика моей работы такова, что все устройства, на которых работают продукты нашей компании, у меня есть. Но если у типичного разработчика телефон только свой и ещё не той платформы — ему не повезло.



— На кнопочном телефоне есть Opera Mini.



— Я иногда захожу в магазин, ищу всякие телефоны с кнопочками, какие-нибудь Nokia. Они всё ещё продолжают выпускать простые мобилки. Если раньше там стоял какой-нибудь свой браузер, то в позапрошлом году мы заключили с ними контракт, что они все свои телефоны серии S, работающие на Java, в итоге перевели на наше решение — на все новые телефоны они теперь ставят Opera Mini.



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



— Это было не напрямую связано с Opera Mini, потому что там другие вещи происходят, принципиально гораздо более тяжёлые и злые. Мы пропускали трафик через себя, соответственно, картинки сжимались — сначала просто более сильным jpg, потом начали использовать WebP и так далее.



Но Opera Mini подошла к тому моменту, когда она всё ещё популярна, но какие-то сайты в ней ещё не работают. Клиентский рендеренг в Opera Mini работать не будет, потому что JavaScript не может исполняться сразу. Нужно сходить на сервер, да ещё чтобы по дороге ничего не поломалось, и вернуться обратно. Для того, чтобы отрисовать следующий кадр, например, выпавшее меню, — нужно сходить на сервер. Это слишком долго. Поэтому мы продолжаем работать над технологиями, которые позволят сжимать так же сильно, как Opera Mini, но работают по-другому.



— А Opera Mini развивается или нет? Это интернет для старых телефонов или это, скажем, какие-то embedded устройства, или телевизоры?



— Когда-то Opera Mini работала на простых кнопочных мобилках, потом мы запустили Opera Mini для Android — это полноценный браузер, где есть закладки, интерфейс, кнопочки, touch и прочее. Но страница рендерится всё равно на сервере.



Запуск Opera Mini для iOS был интересным поворотным моментом. Там было 3 режима сжатия: там есть обычный Safari-движок, потому что на iOS другого быть не может, Safari со сжатыми картинками и просто Opera Mini. И ты мог переключать режимы сжатия в зависимости от того, насколько тебе нужно экономить трафик и быть совместимым. Как мне рассказал Кристин Урибе, Product Manager Opera Mini, сжатие в режиме Mini происзодит немного по-разному, в зависимости от устройства. На айфоне люди привыкли к картинкам бОльшего качества, и поэтому им выдаются менее сжатые картинки. А для маленьких мобилок работает более сильное сжатие.



Нынче мы ушли с обычных мобилок на большие устройства. На многих рынках у нас два полноценных браузера для Android — Opera и Opera Mini. У Opera — свой движок, рендеринг происходит прямо на телефоне. Всё рисуется с помощью Chromium-движка. В Opera Mini рендеринг работает на сервере, всё сжато, некоторый фичи, допустим, JavaScript, вообще не работают. И вот что интересно: люди всё чаще выбирают Opera Mini на своём мощном смартфоне!



— А с инженерной точки зрения, чем отличаются Opera и Opera Mini?



— Визуально они выглядят одинаково, но страницы в них рендерятся по-разному. В итоге люди в странах, где трафик дорогой, плохой, сети перегружены — какие-нибудь азиатские или африканские страны, — они часто выбираю Opera Mini. У них 3G начались раньше, чем нормальный Интернет по проводам. Соответственно, сети перегружены, все в Интернет выходят исключительно с мобильных телефонов. И там совсем другие проблемы нам нужно решать.



Про RFID метки и поддержку биконов браузерами



— Как меняется веб в связи с API для геолокации? Я знаю такой пример: выходишь из метро, и твой провайдер, у которого заключён контракт с ближайшей пивнухой и есть данные по температуре воздуха с Gismeteo, посылает тебе SMS: «Что-то жарко. Не хочешь ли ты выпить холодненькое пиво в такой-то пивнухе?». Веб реально становится таким, каким мы его никогда не видели: в нём появляются гео-данные, появляется big data… Что ты думаешь об этом? Может быть, Opera в этой области что-то делает?



— Мы где-то в августе выпустили поддержку биконов — физического веба, просто экспериментальную сборку Opera для Android. И это было нашей попыткой исследовать эту область. Это RFID-метки в реальном мире, которые транслируются в браузер. Если у вас открыт браузер на телефоне, он вам присылает уведомления в Android о том, что есть какая-то метка. Например, вы подходите к автобусной остановке и можете на вашем смартфоне посмотреть расписание автобуса.



— Сама Opera шлёт мне уведомления?



— Да. Браузер умеет работать с этими метками. Не Android как таковой, а именно браузер.



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



— Если поставить такой бикон на выходе из метро, то мне даже не нужно с

провайдером связываться…




— Да, Opera сама тебе предложит какую-то вещь, связанную с локацией. И это был, кстати, один из случаев, когда мы опередили Chromium, потому что в Chrome это началось совсем недавно. А мы это успели сделать в августе 2015-ого. Хотя движок у нас один и тот же. Просто мы вложились в эксперимент чуть больше, поторопились с ним, чтобы попробовать какие-то вещи. И вот, на том же Chrome Dev Summit, про который я говорил, каждому участнику выдали маленький бикон. В итоге 400 человек ушли оттуда с маленькими этими штучками, которые можно было запрограммировать.



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



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

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



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



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




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

https://habrahabr.ru/post/305394/

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

Мусульманская Европа ждет Украину

Вторник, 05 Июля 2016 г. 18:36 (ссылка)
infopolk.ru/1/U/events/8000...b63e01cc03


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

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

IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5 (2015) Видеокурс » SoftLabirint.Ru: Скачать бесплатно и без регистрации - Самые Популярные Новости Интернета

Четверг, 30 Июня 2016 г. 16:52 (ссылка)
softlabirint.ru/soft/hack/2...okurs.html


IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5 (2015) Видеокурс

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



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



Стань сертифицированным Хакером изучив следующие темы:

-Развенчивание мифов о взломе и безопасности

-IT Безопасность от новичка до продвинутого

-Угрозы Microsoft Windows и слабые места Wi-Fi

-Текущие угрозы и тенденции Черных Шляп (IT конференция)

-Проектирование безопасных сетей

-Зашифрованные данные, определение спуфинг атак, и авторизация Windows

-Экзаменационная подготова Академии IT Безопасности



Улучшение Сетевой Безопасности и Определение Слабостей

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



Содержание и обзор

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



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



Требования

-Базовое знание IT

-Навыки программирования в этом курсе не понадобятся



Что я получу от этого курса?

*Тренды IT Безопасности

*Мифы о Безопасности

*Стандарты Wi-Fi сетей и способы их защиты

*Wi-Fi угрозы

*Понимание Windows безопасности

*Границы безопасности

*Как бороться с вредоносными программами

*Разбор секретов по получению доступа и контроля над Windows

*Как работает Windows аутентификация

*Определение спуфинг атак

*Найдем механизмы авторизации Windows

*7 механизмов Windows безопасности

*Как расшифровать данные Windows

*Wi-Fi сети. Стандарты и защита

*Угрозы Wi-Fi сетей.



Целевая аудитория?

*Будущие Профессионалы в IT Безопасности

*IT Студенты

*Программисты

*IT Энтузиасты

 



IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5 (2015) Видеокурс



IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5 (2015) Видеокурс



IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5 (2015) Видеокурс






Информация о видеокурсе

Название: IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5

Автор: Коллектив

Год выхода: 2015

Жанр: Видеокурс

Язык: Русская озвучка

Выпущено: IT Security Academy Hacking School

Продолжительность: 10:06:53



Файл

Формат: MP4

Видео: AVC, 1280x720, ~724 Kbps

Аудио: AAC, 192 Kbps, 48.0 KHz

Размер: 3.12 Gb



Скачать: IT Безопасность для начинающих 2.0: Курс по взлому. Часть 1-5 (2015) Видеокурс >>>



 



Подписка на новости сайта…

http://feeds.feedburner.com/Soft-Labirint

http://feeds.feedburner.com/Soft-Labirint?format=xml

https://feedburner.google.com/fb/a/mailverify?uri=Soft-Labirint

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

Как bot-to-bot в ближайшее время может заменить API-интерфейсы

Среда, 29 Июня 2016 г. 18:39 (ссылка)

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







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



Смерть API?



На сегодня, когда две системы программного обеспечения могут говорить друг с другом, разработчикам ПО необходимо осуществить интеграцию с использованием API (интерфейсы программирования приложений). Этот процесс отнимает много времени. Вот почему за последние несколько лет стали популярны такие услуги, как Zapier, Scribe и FTT. Они обеспечивают исключительные интерфейсы для сотен приложений, позволяя Вам присоединить, например, Вашу систему CRM к инструментами рассылки или платформой аналитики.



Однако, в эпоху bot-to-bot программные приложения могут говорить с системами друг друга, независимо от того имеют ли они существующую интеграцию API. Конечно, общение bot-to-bot не будет использовать обмен большим количеством данных, но оно создаст специальную связь между, например, пользовательским банковским программным обеспечением и интернет-магазином. Банковское ПО может поговорить с ботом интернет-магазина и попросить потерянный счет: «Моему клиенту нужен счет для заказа 45678, можете ли Вы предоставить его?».



Большой финал: bot-to-bot-to-consume



Красотой общения bot-to-bot является то, что оно будет происходить на простом английском языке; это будет разговор, который сможет понять каждый человек. При условии, что все разговоры между моим ботом Энни и другими ботами попадают в архив, я смогу вернуться и посмотреть, как они пришли к определенному выводу. В моем банковском примере, когда счет остается потерянным, я могу нажать на кнопку «подробнее» и открыть разговор Энни с интернет-магазином.



Но дальше все еще интереснее. Если мой бот зашел в тупик в разговоре с другим ботом, она может позвать меня на помощь: «Привет, это Энни, твой финансовый бот. Я разговариваю с поставщиком, но у меня возникают некоторые трудности в понимании того, что он мне говорит». Я могу присоединиться — конечно, если у меня есть несколько свободных часов (поскольку терпение ботов неограниченно) и перефразировать вопрос Энни, чтобы получить ответ от другого бота. Далее Энни может продолжать разговор и управлять моими делами.



Семантическая паутина



Разве мы не говорили 10 лет назад о присоединении одного онлайн сервиса к другому? Как оно называлось? Правильно, семантическая паутина. Каждый веб-сайт собирался быть аннотированным с использованием стандартных форматов данных, позволяя другим сервисам сканировать эти данные и использовать их в своей бизнес-логике. Я считаю, что боты будут выполнять подобное в ближайшие 3-5 лет и это означает, что все данные будут равномерно отформатированы. Вместо них боты продемонстрируют онлайн сервисы и данные на простом английском языке, позволяя людям и другим ботам взаимодействовать, даже если они ранее никогда не общались.



Созыв всех разработчиков программного обеспечения



Итак, разработчики программного обеспечения, когда Вы разрабатываете Вашу платформу для электронной коммерции, онлайн маркетинга, финансов, системы ERP (планирование ресурсов предприятия) или любого другого программного решения, пожалуйста, подумайте о реализации смарт-бот, кроме вашего традиционного API интерфейса.



Ссылка на оригинал статья
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/262539/

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

Об относительной яркости, или насколько живучим бывает легаси

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

Я уверен, что многим программистам знакома формула:



Y = 0.299 R + 0.587 G + 0.114 B


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



Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.



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



Но почему нельзя? И откуда же взялись именно такие коэффициенты?



Мини-экскурс в историю



Есть такая международная организация, которая разрабатывает рекомендации (де-факто стандарты) для сферы телерадиокоммуникаций — ITU.



Интересующие нас параметры прописаны в рекомендациях ITU-R BT.601, принятых в 1982 году (по ссылке обновленная редакция). Уже на этом моменте можно слегка удивиться — где мы и где 82-ой год? Но это только начало.



Циферки перекочевали туда из рекомендаций ITU-R BT.470 от 1970 года (по ссылке также обновленная редакция).



А они, в свою очередь — наследие цветовой модели YIQ, которая была разработана для североамериканской системы телевещания NTSC в 1953 году! К нынешним компьютерам и гаджетам она имеет отношение чуть более, чем никакое.



Никому не напоминает байку про связь космических кораблей с шириной древнеримской лошадиной задницы?



Современные колориметрические параметеры начали выкристаллизовываться в 1970 году с модернизацией систем PAL/SECAM. Примерно в это же время американцы придумали свою спецификацию SMPTE-C на аналогичные люминофоры, но NTSC перешла на них только в 1987 году. Я не знаю наверняка, но подозреваю, что именно этой задержкой объясняется сам факт рождения пресловутых Rec.601 — ведь по большому счету, они морально устарели уже к моменту своего появления.



Потом в 1990 году случились новые рекомендации ITU-R BT.709, а в 1996 на их основе придумали стандарт sRGB, который захватил мир и царствует (в потребительском секторе) по сей день. Альтернативы ему существуют, но все они востребованы в узкоспецифичных областях. И прошло уже, ни много ни мало, 20 лет — не пора бы уже избавиться от атавизмов окончательно?



Так в чем же конкретно проблема?



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



Любое RGB-пространство (а YIQ это преобразование над моделью RGB) определяется тремя базовыми параметрами:



1. Хроматическими координатами трех основных цветов (они называются primaries);

2. Хроматическими координатами белой точки (white point или reference white);

3. Гамма-коррекцией.



Хроматические координаты принято задавать в системе CIE xyY. Регистр букв в данном случае важен: cтрочные xy соответствуют координатам на хроматической диаграмме (всем известная «подкова»), а заглавный Y — это яркость из вектора CIE XYZ.



Теперь посмотрим на компоненту Y у всех первичных цветов NTSC (я пометил их розовым):





* Оригинал таблицы со многими другими пространствами на сайте Брюса Линдблума.



Знакомая цифирь, правда? Вот и ответ на вопрос «откуда взялось?»



А проблема в том, что используемое сегодня пространство sRGB существенно отличается от системы 60-летней давности. И дело даже не в том, что из них лучше или хуже — они просто разные:







Треугольник шире и смещён в сторону. Другая белая точка. К слову сказать, иллюминант C уже очень давно признан deprecated в пользу иллюминантов серии D вообще и наиболее популярного D65 в частности. Тело цветового охвата другое — соответственно, результаты вычислений яркости окажутся неадекватны реальности.



Вы можете спросить: а зачем древнему NTSC охват (практически совпадает с охватом Adobe RGB 1998!) настолько больше, чем у современного sRGB? Я не знаю. Совершенно очевидно, что кинескопы того времени покрыть его не могли. Быть может, хотели сделать задел на будущее?



Как правильно?



Относительные яркости первичных цветов в пространстве sRGB приведены в таблице выше (помечены зеленым) — их и нужно использовать. На практике обычно делают округление до 4-х знаков:



Y = 0.2126 R + 0.7152 G + 0.0722 B


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



Этой формулы хватит для 99% обычных случаев. Её использует во всех своих спецификациях W3C (например, матричные фильтры в SVG). Если вам нужна бОльшая точность, придется вычислять L*, но это отдельная большая тема. Неплохой ответ на StackOverflow, который дает отправные точки для дальнейшего чтения.



Почему меня это волнует?



Как уже было сказано выше, за многие годы формула растиражирована на несметном количестве сайтов, и они сидят в топе всех поисковиков (например). Источники посерьезнее часто приводят обе формулы, но не делают между ними должного различия, преподнося их как равноправные альтернативы. Характерный пример на StackОverflow: Formula to determine brightness of RGB color — ответы довольно подробные, но человеку не в теме сложно сделать осознанный выбор.



Справедливости ради, серьезные проекты такими ошибками почти не страдают — авторы не брезгуют сверяться со стандартами, да и фидбек аудитории работает (хотя и там не обходится без исключений). А вот рядовой программист, которому нужно побыстрее решить задачу, вбивает в поисковик что-то типа «rgb to grayscale», и тот подсовывает ему сами знаете что. Формулу продолжают находить и копипастить до сих пор! Феноменальная живучесть.



На розыск этих примеров я потратил около 20 минут:





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



А поводом для написания этой заметки стал слайд из доклада Василики Климовой с HolyJS-2016 — с той же самой доисторической формулой. Понятно, что формула не повлияла на основной смысл выступления, но наглядно продемонстрировала ваши шансы ненароком её нагуглить в 2016 году.



Подытоживая: если увидите в чьем-то действующем коде последовательность 299/587/114 — кидайте автору ссылку на эту заметку.
Original source: habrahabr.ru.

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

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

Построение цепочки доверия в PKI, так ли все просто

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

Инфраструктура открытых ключей (PKI) – достаточно популярная технология для обеспечения целостности и доказательства авторства в различных ИТ-системах. Порою о ее использовании человек, сидящий за компьютером, даже не подозревает, как и в случае проверки целостности программы при установке на компьютер.Технология PKI не нова. Если считать от момента возникновения алгоритма Меркле по распределению ключа – то технологии уже 42 года, если считать от момента возникновения RSA – то 39 лет. Возраст в любом случае внушительный. За это время технология существенно эволюционировала и позволяет создать солидный список сервисов для других приложений и пользователей.Сами сервисы регламентированы в ряде стандартов, в серии X.500 – это серия стандартов ITU-T (1993 г.) для службы распределенного каталога сети и серии RFC (Request for Comments) – документ из серии пронумерованных информационных документов Интернета, охватывающих технические спецификации и стандарты, широко используемые во Всемирной сети. Причем серия RFC первична. Основная масса RFC о PKI была выпущена компанией RSA, одной из отцов(мам)-основателей технологии PKI.Отдельно следует упомянуть всякого рода национальные стандарты и нормативные требования, к примеру, в РФ это ФЗ-63, приказы ФСБ России № 795 и 796 и прочие производные от них. Следует учитывать, что многообразие стандартов RFC и описанных в них функций PKI породило несколько организационно-нормативных подходов к построению инфраструктуры PKI в отдельно взятой стране. Для иллюстрации приведу список сервисов PKI, которые описаны в стандарте X.842:Key Management Services1 Key Generation Service2 Key Registration Service3 Key Certification Service4 Key Distribution Service5 Key Installation Service6 Key Storage Service7 Key Derivation Service8 Key Archiving Service9 Key Revocation Service10 Key Destruction ServiceCertificate Management Services1 Public Key Certificate Service2 Privilege Attribute Service3 On-line Authentication Service Based on Certificates4 Revocation of Certificates ServiceElectronic Notary Public Services1 Evidence Generation Service2 Evidence Storage Service3 Arbitration Service4 Notary Authority5 Electronic Digital Archiving ServiceOther Services1 Directory ServiceIdentification and Authentication Service1 On-line Authentication Service2 Off-line Authentication Service3 In-line Authentication Service3 In-line Translation ServiceRecovery Services1 Key Recovery Services2 Data Recovery Services5 Personalisation Service6 Access Control Service7 Incident Reporting and Alert Management ServiceРезультатом этого многообразия стало безобразие в национальных стандартах отдельных стран. Как результат – набор проблем по совместимости между различными решениями в отдельных странах и, очень часто, невозможность построения цепочки доверия между двумя пользователями технологии PKI в разных странах.Прежде чем рассматривать вопрос методики построения трансграничного доверия, хотелось бы разобрать вопрос построения цепочки доверия внутри страны, взяв за пример РФ.Для этого кратко опишу, как вообще строится базовая инфраструктура PKI и какие есть методы обеспечения доверия в PKI.Доверие в PKI строится по принципу поручительства – например, если два человека не знают друг друга, но хотят вступить в отношения, которые требуют взаимного доверия, они ищут третьего, кому бы могли доверять они оба и кто бы поручился за каждого из них перед другим. Аналог такого человека в PKI называется третья доверенная сторона.Одной из областей применения PKI является обеспечение юридической значимости электронного документооборота. То есть обеспечение возможности доверять электронной подписи под электронным документом. Но, следует уточнить обеспечение юридической значимости требует выполнения целого ряда условий, одним из которых является построение цепочки сертификации. В рамках данной статьи, я хотел бы детально рассмотреть только саму процедуру построения цепочки сертификации и ее взаимосвязи с цепочкой доверия.Цепочка доверия между людьми строится при помощи построения цепочки сертификации. Делается это следующим образом: в роли третьей доверенной стороны выступает аккредитованный удостоверяющий центр. Это юридическое лицо, обладающее одним или несколькими наборами оборудования, которое реализует функции удостоверяющего центра. Аккредитация означает, что это юридическое лицо отвечает ряду требований законодательства, у него есть соответствующие лицензии ФСБ, Минкомсвязи и иногда ФСТЭК России, должным образом оборудованные помещения, обученный персонал с правильными дипломами и сертифицированные ПО и оборудование в роли удостоверяющего центра (УЦ). Так вот, этот удостоверяющий центр уполномочен государством подтверждать вашу электронную подпись другим лицам. Процедура подтверждения вашей электронной подписи удостоверяющим центром является процессом создания цепочки сертификации, так как сертификат УЦ так же подписывается Главным удостоверяющим центром (ГУЦ), который является единой точкой доверия. Что такое электронная подпись и как она работает – вопрос за рамками данной статьи, об этом можно почитать в других источниках.Для того чтобы этот УЦ мог точно сказать, что под документом именно ваша подпись, вам надо прийти в центр регистрации этого УЦ и предоставить ваш открытый ключ, запрос на сертификат, паспорт и ряд других документов. В результате вы получите сертификат открытого ключа, подписанный на ключе данного УЦ. Аналогом этого являются 2-я и 3-я страницы внутреннего паспорта гражданина РФ, там тоже стоит ваша уникальная подпись, ФИО и указано, какой орган эти данные заверил. Но есть небольшое различие – в случае паспорта доверие к его носителю строится через подтверждение подлинности самого паспорта, а потом уже через данные, которые в нем указаны. В электронном мире УЦ принято доверять, только если оба пользователя, которые пытаются общаться между собой, обслуживаются в этом УЦ. В случае если УЦ у каждого пользователя свой, встает проблема доверия между УЦ. Путей ее решения несколько, путь снизу подразумевает кросс-сертификацию между УЦ разных пользователей. Такой путь хорош, когда УЦ не много, но если каждое ведомство развернет себе свой УЦ, получится ситуация, которая возникла в РФ к 2002–2005 годам: множество УЦ по стране, а единого пространства доверия нет, так как кросс-сертификация среди 800 УЦ – штука технически нереальная.И вот тут возникает вопрос – как построить единое пространство доверия в отдельно взятой стране так, чтобы оно работало. Подход, который используется в РФ и не только – создание Главного удостоверяющего центра (государственного) (ГУЦ), подпись его сертификатом всех сертификатов УЦ в стране, как результат – построение цепочки доверия через проверку действительности всех сертификатов в подписи через ГУЦ. Такой подход подразумевает, что проверяются подпись пользователя, действительность сертификата пользователя, действительность всех сертификатов в цепочке (УЦ–ГУЦ). Проверка действительности сертификатов в различных странах производится по-разному. В Эстонии и на Украине для этого требуется обратиться к OCSP/TSP-службе ГУЦ, которая ответит – действующий сертификат или же срок действия истек или сертификат отозван. В России для проверки надо запросить у каждого УЦ в цепочке список отозванных сертификатов (СОС) и проверить, что сертификат в нем не указан. Пожалуй, наиболее развитым вариантом построения системы PKI следует считать схему с использованием мостообразующего УЦ, в том виде, в котором она используется в США. Федеральный мостообразующий УЦ (бридж) США содержит несколько базовых служб функции которых следует разобрать в отдельной статье. И вот в этот момент начинаются сложности. Сложность первая. Случается, что сертификат пользователя заполнен неправильно, не соответствует требованиям законодательства, в этом случае он должен быть перевыпущен. Как правило, подобную проблему порождает работник УЦ, который неправильно его заполнил, а проблемы получает пользователь, когда не может его нормально использовать.Сложность вторая. Законодательство говорит о том, что УЦ – это юридическое лицо, и ГУЦ должен подписать сертификат этого УЦ. Ситуация, когда у одного юридического лица несколько комплексов УЦ и несколько сертификатов этих УЦ, толком в законах не прописана. УЦ этим пользуются, часть сертификатов не подписывают с помощью сертификата ГУЦ и делают их в лучшем случае самовыпущенными – когда цепочку к ГУЦ можно построить только по имени УЦ в сертификате – или вообще самоподписанными – когда связи между сертификатами одного УЦ технически не существует, она есть только на бумаге.Сложность третья. Если сертификат отозвали, УЦ обязан его добавить в список отозванных сертификатов (СОС), обязанность эта прописывается в RFC, если они приняты как стандарт в стране, или в регламенте ГУЦ, к которому обязаны присоединиться все аккредитованные УЦ. В случае когда СОС (CRL) большой, УЦ для удобства пользователей выпускает дельта СОС (deltaCRL) с изменениями за короткий период. В регламенте ГУЦ прописана периодичность обновления 12 часов или по факту отзыва сертификатов. В реальности различные УЦ свои СОС публикуют как хотят, существуют некоторые УЦ, которые обновляют их 1 раз в несколько месяцев. Или же СОС подписывается ключом, который не имеет отношения к сертификату УЦ, что тоже сводит шанс построить цепочку доверия к нулю. Потихоньку возникает проблема с обработкой самих СОС, за время существования УЦ они уже стали достаточно большого размера, но дельта СОС не выпускает почти никто.Сложность четвертая, связная. Построение цепочки доверия в PKI так или иначе требует наличия связи с УЦ и ГУЦ и работу в онлайне. Работа в офлайне не предусмотрена. Существует ряд мест и приложений, где работа с подписями и сертификатами в офлайне очень бы пригодилась. Далеко не вся территория РФ охвачена качественным интернетом и каждый лишний передаваемый байт воспринимается болезненно, так как бьет по кошельку.Сложность пятая, техническая. Иногда в программно-аппаратных комплексах УЦ все-таки находятся ошибки в логике и реализации, это также может влиять на построение цепочки доверия.И только если на пути пользователя эти проблемы не встретились, цепочка доверия должна построиться. В случае использования OCSP/TSP-служб проблемы тоже существуют, но это тема для отдельной статьи.

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

https://habrahabr.ru/post/304220/

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

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

Среда, 22 Июня 2016 г. 17:26 (ссылка)

image



Московская биржа стала участником международного блокчейн-консорциума HyperLedger и присоединилась к проекту Linux Foundation, в рамках которого функционирует этот консорциум.



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



Сергей Поляков, Управляющий директор по информационным технологиям Московской биржи: «Технология распределенного реестра приобретает все больший вес в финансовой индустрии. Группа „Московская биржа“ активно изучает перспективы применения блокчейн-решений в процессах проведения торгов, клиринга и расчетов. Первые результаты нашей работы уже применяются: Национальный расчетный депозитарий развивает пилотный проект системы электронного голосования владельцев облигаций e-proxy voting на основе этой технологии».



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



О HyperLedger Project

image



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



HyperLedger Project организует площадку для коммуникационных сессий бизнеса и разработчиков, способствует формированию общепризнанных международных блокчейн-стандартов в финансовой индустрии. Проект объединяет как глобальных игроков мирового финансового рынка (CME, Deutsche Boerse, LSE), так и крупные IT–компании (IBM, CISCO, Intel).



В проекте HyperLedger функционируют технический комитет (Technical Steering Committee), маркетинговый комитет (Marketing Committee) и технический консультативный совет конечных пользователей (End User Technical Advisory Board). Представители Московской Биржи и НРД войдут в состав всех комитетов и рабочих групп блокчейн-консорциума.

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

https://habrahabr.ru/post/303874/

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

Суровый рынок веб-разработки в России или зачем нам базы данных, постоянное хранилище и FTP

Среда, 15 Июня 2016 г. 21:20 (ссылка)

image




Чем бы дитя ни тешилось, лишь бы по FTP не деплоило и не масштабировало свои продукты, перекачивая образы виртуальных машин. Респект и хвала умным парням и девушкам, которые знают, что такое CI, CD и активно их используют в своем продакшне. Cust Dev по России показал, что все очень плохо. Увы.



Крик души



Соблюдаем анонимность и надеемся никого не обидеть. На вопрос “Как вы работаете и доставляете свой продукт в продакшн?” мы услышали уйму различных ответов. Вот некоторые тезисы из самых популярных ответов:


  1. Я не пользуюсь ide, все делаю через админку вордпресса, ручками открывая файлы с фтпшника в саблайме.

  2. Разворачиваем новые экземпляры своего SaaS, копируя целиком виртуалки. За ночь копируется нормально.

  3. Как-как? По ftp, а git используем для резервных копий.

  4. Мы планировали использовать git, но как-то не получилось. Сейчас все руками.

  5. У меня все настроено с помощью капистрано.

  6. Все через пулл-реквесты, потом суровый код-ревью, потом CI подтягивает все в прод.





Это не сферические кони в вакууме, а реальные люди из реальных студий и агентств России из крупных и мелких городов. На удивление различия в относительных долях того или иного ответа в зависимости от региона оказались несущественными. Быть может, для небольшого и несерьезного проекта, типа сайта-одностраничника, подобный подход вполне себе вменяемый, но если ты ответственный за DevOps в более-менее крупной веб-студии, для безболезненного масштабирования просто жизненно-необходимо придерживаться git workflow и использования ряда CI/CD инструментов.



SaaS масштабирование



Боль у каждого своя, и как использовать тот или иной инструмент решает каждый сам. Если вы — счастливый обладатель SaaS решения (системы мониторинга, CRM, CMS, в общем, все, где нужно масштабироваться быстро по горизонтали) и вы до сих пор клонируете виртуозки, то бог вам в помощь мы вас ждем. Пишите нам в саппорт, и мы предложим вам выгодные условия использования нашей платформы для обеспечения быстрого масштабирования. Небольшое демо такого прикладного использования нашей системы









Использование системы не по назначению, перманентное хранилище и FTP



Есть то, что есть, и работать приходится именно с этим. Особенности работы Docker образов и контейнеров включают в себя определенные ограничения для файловых операций внутри контейнера, а именно — неперсистентность результата их выполнения после перезапуска процесса веб-сервера (что порождает пересоздание контейнера) или перебилда image вашего приложения. Мы, хоть и косвенно, но являемся Shared CaaS решением. Наше предложение — хранищище с FTP доступом из вне. Папка монтируется в контейнер при билде и запуске приложения.



Для любителей писать на шаблонизаторе php систем эта проблема наиболее актуальна, ибо 90% написанных решений безбожно творят уйму операций с файлами, сохраняют туда данные, конфиги, темы, настройки и пр. Если взять пример запуска веб-сервера, совместимого с большинством php-систем (наличие апача для многих является просто необходимым) https://github.com/dokkur/php-common/blob/master/Procfile, то мы в самом простейшем варианте даем возможность закинуть все необходимое содержимое в примонтированную папку через FTP. Для этого нужно:


  1. Зарегистрироваться у нас

  2. Нажать кнопку + справа вверху

  3. Ввести имя приложения, выбрать датацентр

  4. Выбрать нужный темплейт — Any PHP

  5. Дождаться окончания создания приложения, перейти в п.меню Storage

  6. Кликнуть на строку /app/www и получить данные для подключения: Host, Username, Password. Если изменения DNS еще не настигли ваш узел связи или у вас закешировано там что-то другое, то советуем использовать доменное имя инстанса, на котором создано ваше приложение: п.меню Settings, посмотреть на git url и прочитать хостнейм — то, что между символами “@” и ”:”.



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



Что делать и кто виноват?



Виноваты все по чуть-чуть никто не виноват и что делать решает каждый сам для себя.



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



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



Что наиболее точно характеризует вас:


































































































Проголосовало 3 человека. Воздержавшихся нет.





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


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

https://habrahabr.ru/post/303388/

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

Следующие 30  »

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

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

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