Прошло несколько месяцев с момента обнаружения уязвимости Shellshock (CVE 2014-6271) в командной оболочке Bash, но до сих пор не все сисадмины позаботились о том, чтобы установить патчи. Специалисты из компании Binary Defense Systems обнаружили активную кампанию по организации ботнет-сети через заражение почтовых SMTP-серверов.

Заражение осуществляется через служебные поля в письме “subject”, “body”, “to”, “from”. Каждое из них используется для загрузки perl-скрипта для ботнета. После загрузки и активации бот подключается к IRC-каналу и ждёт дальнейших инструкций.

На скриншоте показано содержимое письма, которое рассылается для использования уязвимости Shellshock в SMTP-серверах.

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

Bash часто используется на компьютерах под управлением Linux, UNIX и Mac OS X, так что все они требуют обновления.

Яков Файн — организатор Princeton Java Users Group, является автором и соавтором большого числа технических книг по программированию, например Enterprise Web Development, (O’Reilly, 2014), Java 24-Hour Trainer (Wrox, 2011).

Специалист Luxoft Training в области Web-, XML- и Java-технологий Вячеслав Лапин (В. Л.) взял интервью у одного из основателей двух стартапов — IT-консалтинговой компании Farata Systems и компании по разработке ПО SuranceBay, Java Champion Якова Файна (Я. Ф.).

В. Л.: Здравствуйте!

Я. Ф.: Добрый день.

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

Я.Ф.: Но я бы обобщил, что есть несколько основных направлений:

Подход «Native JavaScript» — попытки максимизировать использование потенциала, заложенного стандартами от ECMA  и W3C-консорциума . Вы знаете, что время от времени выходят новые версии этих стандартов, появляются новые features, и есть проекты типа JavaScript 6 Shim  и Traceur , которые вкупе с современными средствами разработки, такими как WebStorm, еще до официального выхода стандартов и их реализации в браузерах позволяют пользоваться этим инструментарием. Соответственно, подход состоит в том, чтобы решать задачи в основном с опорой на эти инструменты .

Это было бы очень даже удивительно. Я в 2005 году попал в такую финансовую компанию и был очень удивлен, что один человек сидел за большим белым компьютером Apple, когда все остальные работали на стандартных Windows-машинах. Тогда это было очень странно. А сегодня есть целая политика, есть целая стратегия, какие устройства можно разрешать брать внутренним юзерам, а какие — нет.

Иными словами, я уже говорил, если мы находимся внутри стен одной организации, знаем environment (окружение), то мы можем выбрать один подход. Но даже это, так сказать, не «written stone» (высечено в камне), так как эта политика BYOD тоже может разрешить им приносить свои iPad’ы или Android’ы.

Вторая категория — есть Consumer Facing Applications, то есть приложения, где пользователями являются люди, не находящиеся внутри организации. У них могут быть совершенно любые устройства. И вот тут перед разработчиками уже встает другая проблема — как сделать так, чтобы то, что я напишу, выглядело нормально на всех устройствах, о части которых я сегодня еще даже не знаю. Завтра выйдет iPhone 6 или какое-то небольшое китайское приложение. Подходы совершенно разные.

Ну а теперь, возвращаясь, дам короткий ответ. Вот эти подходы, которые вы обозначили, брать ли обыкновенный JavaScript? Новый стандарт JavaScript 6  — на него можно пока не смотреть, потому что в ближайшие пару лет он не выйдет, а когда он выйдет, браузерам понадобится какое-то время, чтобы его имплементировать. Но уже сегодня ECMAScript 5  поддерживается практически всеми современными браузерами. Под современными я подразумеваю браузеры, которые не старше двух лет. На самом деле в разработке сегодня мы стараемся не принимать во внимание старые браузеры. Например, все, что ниже IE 9, мы даже не рассматриваем, то есть если не будет работать — ну извините, пора бы уже и подтянуться! С другой стороны, что касается фреймворков, о которых вы сказали (jQuery, AngularJS, Ext JS, Backbon.JS), их тоже можно разделить на разные группы. А именно:

Тяжеловесы, такие как Ext JS или Yahoo YUI , который уже прекратили поддерживать, сказали: «все — мы поняли, что это тупик». Тяжеловесные фреймворки годятся для Enterprise-приложений, приложений корпоративных. Ext JS — есть хорошие контроллеры, очень сильные Data Grid, можно формы делать, там есть Charting хороший, то есть можно делать так, чтобы одни и те же данные показывались как pie diagram либо bar diagram. Тут же click on the button, и это уже таблица с циферками. Вот эти все вещи для приложений для корпораций хороши. Минусом же является то, что фреймворк тяжелый. То есть само приложение будет весить много: ваш код + мегабайт. Это много, если это Consumer facing application. Если человек стоит на какой-то медленной сети с мобильником в руках и ему приходит больше 1,5 Мб только, чтобы загрузиться, то это минус. Хотя это rich library — богатая библиотека, в которой есть куча консолей. И если вам это действительно важно — нужно сделать солидное красивое приложение для внутреннего использования в компании. Или так называемое back office operations, то есть для своих юзеров. Да, можно рассматривать эту библиотеку.

В большей части признают легкие. Для легкости используют все-таки другие фреймворки. Для чего пользоваться такими фреймворками, как Angular или jQuery? Во-первых, чтобы упростить себе создание каких-то мелких компонентов, чтобы использовать заготовки, которые уже есть в мире. А во-вторых, чтобы спрятать зависимость от браузеров. Скажем, разные браузеры, может быть, еще не все имплементировали последние feature’и ECMAScript 5, то есть браузер c неполной поддержкой этого стандарта. Эти библиотеки говорят: «Мы от вас спрячем это. Будете работать с нашей библиотекой и не волнуйтесь — поддерживает браузер или нет, — мы будем пользоваться этими feature’ами, ставить специальной загрузкой или еще как-то…»
Вот такой ответ. Я могу еще говорить на эту тему. Но давайте уже перейдем к другим вопросам.

В. Л.: По компилируемым в JavaScript языкам скажите еще пару слов — TypeScript, Dart, другие?

Я. Ф.: Ах да, по языкам. Главный язык — JavaScript. Есть один человек, которого зовут Джефф Этвуд (Jeff Atwood), вместе с Джоэлом Спольски (Joel Spolsky) он создал Stack Overflow. Это популярное место, где программисты собираются и задают друг другу вопросы. И он сказал фразу, которая звучит примерно так: «Все, что может быть написано на JavaScript, — будет написано на JavaScript!»

В принципе, это, конечно, шутка. Но в этой шутке есть доля шутки. Да, действительно, о JavaScript можно говорить все что угодно. Он очень странный, показывает всякие глупости , непредсказуемость неких конструкций. Но «As is what it is» — у нас это есть сегодня, это то, что мы имеем, и это наименьший общий знаменатель для всех приложений. Минусом является что? Резкое снижение продуктивности программистов.

В нашей компании Farata Systems  мы делаем разработку на разных языках, на сервере — Java (базовый, никогда ничего не меняем), на фронтенде мы использовали разные языки, в частности, много лет использовали чудную библиотеку от Adobe — Flex . Компилирующий язык, public client и так далее. Удобно. Хорошо. Наши разработчики были продуктивны. Потом по разным причинам Adobe отказалась от Flex, Apple не хочет поддерживать плагины и браузер-компилятор. Эта технология уходит. И мы стали пересаживать программистов на JavaScript. И сразу увидели резкое падение продуктивности. А у нас работают только Senior-программисты, нет Junior или только начинающих. Мы сразу увидели, что нашим ребятам нужно намного больше времени, чтобы сделать то же самое. Это — большой минус JS.

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

Но когда мы говорим слово Dart, мы должны разделять разработку и production (deployment). Сегодня и еще многие годы это не изменится: на Dart вы разрабатываете, а из Dart генерируется все равно JavaScript, и он запускается в production. Почему? Потому что никакие основные браузеры не собираются поддерживать пока DartVM. У Google есть специальный браузер Chrome , вероятно, скоро и сам Chrome будет идти с DartVM. Другие браузеры не собираются пока его поддерживать и не соберутся. Google это понимает, поэтому генерирует очень хороший JavaScript. Dart — это, по моему мнению и по мнению нашей компании, хорошее направление, куда идти, чтобы сделать разработку на JavaScript более продуктивной.

Некоторые пробовали TypeScript. Но TypeScript — это такое промежуточное решение, которое чуть-чуть лучше, чем JavaScript. А Dart — серьезно лучше! Минус использования Dart — пока еще недостаточная база компонентов UI, которая может быть использована в вашем Dart-приложении. Положительной стороной является то, что в Dart есть библиотека AngularJS, которая на JS написана. Легкая библиотека, MVC и т. д.

А есть уже и AngularDart , во-первых, пишем на Dart, используем AngularDart, и там было мало компонентов. Есть еще такая библиотека Polymer , где все основано на том, что можно создавать компоненты на HTML, то есть из тега можно сделать компоненты, которые потом можно взять, drop’нуть на другой экран и пользоваться там. Это правильное направление, по нашему мнению, и мы идем в эту сторону. Если писать для HTML5 для браузеров, для разных устройств, я бы посоветовал сегодня выбрать Dart с генерацией JavaScript и деплоить в JavaScript.

В. Л.: Спасибо. Тогда следующий вопрос — как раз касательно этой разницы. Как вы оцениваете такой вопрос, который раньше не стоял и появился в связи с ростом популярности JavaScript: строгая типизация — это плюс или минус? И как он влияет на производительность труда программиста? Будущие языки — как они будут разрабатываться — со строгой типизацией или это будут переменные, которым можно будет присваивать любой объект?

Я. Ф.: Ну, этот вопрос можно перефразировать так: «как вы относитесь к острым ножам?» Хорошо иметь на кухне острый нож? Наверно, хорошо. Но вы понимаете, что человек, который только начинает «куховарить», может порезать себе палец? Кого будем винить? Будем винить нож! Правда? Или не нож винить? В этом плане нестрогая типизация — это нож, которым можно порезаться.

Главный минус — программа становится менее читаемой. Конечно, вы можете сказать: «Ну а мне какая разница? Я-то понимаю, я сам написал». Да, но многие могут сказать, что больше времени требуется, чтобы читать чьи-то программы, чей-то код, чем писать свой. Поэтому если Вася Форточкин придет читать программу, которую я писал (а я уже уволился из компании, и это было написано на нетипизированном языке), то Вася очень зависит от меня — от моей доброй воли, от того, насколько я хороший программист, насколько я правильно называл переменные, потому что типов нет. Более того, динамические языки программирования, такие как JS, позволяют на ходу менять структуру объектов. Вот у вас есть какой-то объект, допустим Customer. У него несколько полей: имя, фамилия, адрес и т. д. И никогда там не было поля «Номер телефона». На ходу в программе взяли и прикрепили динамически новое поле и пользуемся. А Вася Форточкин откуда это знает? Он, конечно, разберется, но на это уйдет время. Если вас интересует продуктивность, то строгая типизация намного удобнее.

Так как сегодня большинство программистов — это массовые отряды, батальоны, дивизионы, которые слегка где-то подучились и программируют массовые приложения, т. е. ты не можешь ожидать от них суперэкспертности и большой порядочности в написании кода, для них нестрогая типизация — это вредно. А строгая типизация — это плюс, так как компилятор помогает тебе. Он не дает упасть. Ты написал что-то не то, а он подсказывает, не дает это сделать. Скажем, в нестрогой типизации ты сделал опечатку в названии Property (например, был объект клиент Customer, ты написал Customer.adress с одной буквой d равняется чему-то). Если в строгих языках типа Java тебе бы сказали: «нет такого address с одной d», то в нестрогих — промолчит, создаст новое Property «adress», программа будет как-то работать, а результат не тот, что ты ожидал. Поэтому нестрогая типизация, я считаю, не зло. Но требования к уровню программистов выше, чем к тем, кто пользуется языками со строгой типизацией.

Об этом я всегда говорю (мы читаем разные тренинги). В частности, когда мы обучаем Java-программистов, которые считают себя крутыми («мы знаем Java, multithreading, оптимизированные серверы, параллельные обработки и т. д. JavaScript — это бирюльки…»), на наших тренингах у них, наверно, сначала волосы дыбом встают, насколько сложно писать правильный код на JavaScript. Поэтому на месте программистов со строго типизированным языком я бы не смотрел свысока на программистов с нестрого типизированным языком: им тяжелее, чем вам. Это мое обращение к Java’истам.

В. Л.: Большое спасибо. Вам как эксперту не только по JavaScript, но и по Java должна быть знакома ситуация, когда появился Spring, — он изменил все. Это была революция в Java. Последние лет пять я даже не видел проектов на Java, которые бы не использовали Spring (реализация IoC, AOP). Недавно, когда я познакомился с AngularJS , там я увидел похожие подходы, тоже реализован IoC, некоторые конструкции с аспектно-ориентированным программированием. Я подумал, может, это тоже революция и через пару лет мы не будем видеть ни одного клиентского приложения без использования AngularJS? Как вы считаете?

Я. Ф.: Ну, во-первых, почему выделена именно AngularJS? AngularJS — да, хорошая библиотека. Да, она легкая. Да, она имплементирует паттерн MVC (model — view — control). Да, она позволяет разделить код более удобно на слои — там, где отдельно модели, — там, где данные, отдельно вьюшки, отдельно контроллеры. Да, это хорошая вещь. Да, там имплементировано Dependence Injection и IoC (Inversion of Control), то, что вы говорите, т. е. туда применен голливудский принцип «ты мне не звони, я тебе позвоню». Знаете, когда начинающие артисты в Голливуде ищут работу и обивают пороги агентств, после очередного прослушивания им говорят: «Когда тебе позвонить?» Они отвечают: «Ты мне не звони, я тебе позвоню». Это Inversional Control, т. е. не ты создаешь объект, а тебе он будет дан.

В Spring было сделано то же самое. Сегодня Spring популярен. И популярность его в мире Java часто определяется тем, что в то время (в начале 2000-х годов), к сожалению, Java EE архитектура была сложной. И Род Джонсон (Rod Johnson) создал Spring и имплементацию Dependence Injection. Я бы не сказал, что сегодня нет проектов, которые бы не делались на Java EE. Java EE намного проще. Но, к сожалению, они в свое время испортили о себе впечатление из-за сложности.

Сейчас и Enterprise Java Beans, и Managed Objects Injections, и CDI Dependence Injection — все это очень красиво, удобно. Но люди, которые уже сели на Spring, не видят причин пересаживаться на контейнеры JavaApplication-серверов. Параллель между Spring и AngularJS, наверно, только в том, что и там, и там имплементирован механизм Injections. В Java’вских проектах используется Spring, может не весь, а отдельный модуль, например Spring Security — он добавляется в любой проект, даже если это Java EE проект.

AngularJS тоже хороший фреймворк, но это MVC. Для того чтобы иметь full feature с полным набором фреймворков, нужно не только иметь возможность правильно структурировать приложение с распределением на слои. Там нужны некие компоненты, нужны удобства. Поэтому просто использовать AngularJS не очень хорошо, не мешало бы использовать какую-нибудь библиотеку кнопочек с круглыми краями. Какой-нибудь Goodstrap или еще что-нибудь. Я не хочу сказать, что фреймворк типа AngularJS просто возьмет и будет впереди планеты всей. Я так не считаю. Может быть, он будет один из лидеров, он и сегодня — один из лидеров, но не думаю, что это наше будущее. На сегодня он популярен, сегодня очень много проектов на нем делается. Когда будет полностью чисто сделан проект AngularDart, будет еще лучше. Но это — один из самых популярных фреймворков, и он будет жить и процветать какое-то время. И его изучать полезно сегодня, на ближайшие несколько лет это полезное знание. Но это — не революция.

В. Л.: Да, спасибо. Я хотел поговорить о том, что несколько лет назад появился сервер Node.js. Как вы оцениваете его потенциал с точки зрения рынка интернет-проектов и рынка корпоративных приложений: может ли он в перспективе привести к замене Java-, .NET-языков языком JavaScript на сервере? И как вы прогнозируете его дальнейшую судьбу?

Я. Ф.: Понимаете, один из главных принципов, по которому его продают и делают популярным, — это возможность исполнять JavaScript на сервере, на любой машине, скажем так, на своем движке. Программисту говорят: «Теперь тебе достаточно знать только JavaScript. Ты можешь и фронтенд писать на JavaScript, и бэкенд писать на JavaScript».

Я не считаю, что это правильный подход. Почему? Потому что главная задача при выборе языков программирования — чтобы конечный результат и конечный продукт был оптимальным и лучшим и пользователи его любили. Пользователям все равно, на чем написан продукт. Есть там Java, или JavaScript, или .NET — им абсолютно неважно. Им важно — удобно им или неудобно. Разве, когда вы берете в руки свой Android-телефон или iPhone, у вас есть мысль, на чем было написано это приложение? Нет! Вам оно или нравится, или не нравится. Это самое важное для вас. Это должно быть определяющим критерием. А сказать, что надо пользоваться Node.js только потому, что вы сможете пользоваться JS и здесь, и там, — это все равно, что сказать слесарю: мы придумали вариант, чтоб ты пользовался только отверткой. Другие инструменты тебе не нужны. Ты сможешь отверткой делать все: ты можешь выпиливать, не нужен лобзик тебе, отверткой можно выковырять все, в принципе, тоже. Поэтому я считаю, что программист должен быть сегодня полиглотом и знать несколько языков. И если перед вами стоит задача — ваша задача сделать пользователя HAPPY — СЧАСТЛИВЫМ! А не сделать свою среду удобной: я не хочу ничего изучать, кроме JS, поэтому мне удобно.

Что касается перспектив. Во-первых, Node.js еще не был даже выпущен в продакшен. Весь этот шум, который последний год происходит, — это о каких-то версиях, которые еще не являются «продакшен грейн». Во-вторых, что касается «Node.js заменит Java». В каких-то маленьких проектиках — почему нет? Я видел разные Benchmark. Не разные, врать не буду. Но лучший Benchmark, который я видел, — это тот, где Node.js на сервере в определенных приложениях, которые пытались нагрузить, работал в шесть раз медленнее, чем версия Java этого же приложения. По производительности ему до Java как до неба, пока. Хотя в шесть раз — это уже не так плохо для продукта, который даже еще не вышел. Движок, который, в частности, делает Google , а кроме Google, еще Oracle выпустила JavaScript-движок в составе Java 8 (называется Nashorn)  — это тоже движок для JavaScript. Они довольно быстрые и, несомненно, будут ускоряться. Поэтому определенно будущее у Node.js есть, но это — не наше все. И я к этому отношусь совершенно спокойно — есть еще один язык для программирования на сервере.

Прекрасно!

В. Л.: Спасибо. Сейчас я бы хотел отойти от конкретики и задать более абстрактный вопрос по парадигме функционального программирования. Раньше были такие языки — главным образом Lisp , но потом интерес к ним угас. А сейчас мы видим, как они опять выходят на арену. Мы видим на платформе .NET язык F# , на платформе JVM — язык Clojure , да и в самом Java 8 много заимствований из функциональных языков. Как вы считаете — это просто мода или за этими решениями будущее?

Я. Ф.: Я бы не сказал, что это сиюминутная мода, потому что языки, такие как Lisp, уже очень старые. Не то чтобы он очень популярен, но прелесть функционального программирования заключена в том, что оно проще выглядит. Нет, неправильно. Можно короче написать то, на что нужно много кода в объектно-ориентированных языках программирования. Поэтому программисты опытные, грамотные, которые шикарно разбираются в программировании, считают программирование своей профессией, десятилетиями занимаются этим, любят ее, изучают эти языки, пробуют разные, как вы сказали, Clojure, Scala и другие.

Станет ли это массовым? Нет, не станет. Потому что эти языки сложны для изучения, а тем легионам программистов, которых сейчас производят, это сложно. Если в команде будет несколько человек, которые хотят программировать на Scala, это прекрасно. Они сделают отличный продукт, он будет элегантный и все такое.

Но давайте представим следующую ситуацию. Допустим, я менеджер команды на каком-то предприятии и мне нужно начинать разработку нового проекта. И скажем, есть такой крутой парень Джон Смит — эксперт в Scala. Он приходит ко мне в кабинет, здесь же присутствует вся команда. Он говорит: «Яков, давай делать на Scala, посмотри, ты технический человек, вот так я могу быстро, коротко и элегантно написать код». Я понимаю технические плюсы этого. Но с другой стороны, кроме Джона, у меня сидит Мэри, Маша, Ашот, еще и Шреневаз, еще и Петро. И я все думаю — что? Да, Джон крут. Да, Scala выглядит красиво. Но допустим, завтра Джон Смит уходит на другую работу. И я остаюсь с Петром, Машей, Шреневазом, Ашотом и Мэри. И я скажу: «Извини, Джон, может, классный язык Scala, но пока нет. Может, только отдельный модуль можно написать на Scala. Почему? Потому что мы JavaScript-цех. И твои модули могут исполняться на JavaScript-машине».

Большим плюсом, даже огромным плюсом я считаю тот факт, что в Java были введены эти конструкции для функционального программирования. В Java 8 так называемые Lambda Expressions используются в разных местах, они делают код действительно более элегантным. В чем прелесть функционального программирования? В том, что я тебе — объекту даю поведение, записанное как функция. Я тебе говорю: «Вот ты возьми этот код и его выполни». Это плюс.

Я написал несколько блогов, я работаю над вторым изданием своей книги по Java, которая скоро выйдет. Я написал несколько примеров, которые помогают упростить код. Допустим, в обыкновенном Java иерархия наследования — несколько слоев. А с помощью вот этих лямбд я могу убрать эти слои, я могу брать разные кусочки функционала и передавать их одному и тому же объекту. И он послушно это выполнит. В этом плане функциональное программирование — это шикарно. Я считаю, что это полезно знать, но не думаю, что если ты Java-программист, тебе нужно взять и переучиться на другой язык. Хорошо разберись с Java 8, и будет очень красиво! Ну а если ты чувствуешь в себе больший потенциал — изучай больше. То есть функциональные языки — это плюс, но опять же я не думаю, что это наше все. JavaScript, кстати, тоже функциональный язык.

В. Л.: Да, спасибо. Сейчас в мире приложений для мобильных устройств мы наблюдаем картину, к которой не привыкли в области ПК, когда есть две флагманские платформы Apple и Android и под них нет решений, чтобы писать код универсально. Понятно, что есть PhoneGap , есть jQuery Mobile . Но по факту мы видим большинство приложений, которые написаны на Dalvik или Objective-C. Как вы считаете, почему до сих пор не создано настолько же зрелой универсальной платформы разработки, каковой является Java для персональных компьютеров и серверов, чтобы четко соблюдался принцип WORA  и при этом не страдала производительность? Насколько это следствие технической несовместимости этих платформ и насколько — следствие политики конкуренции Google и Apple?

Я. Ф.: Я бы не назвал это политикой. Ну как можно обвинить Google или Apple в том, что они хотят, чтобы был определенный строгий процесс деплоймента на их платформе, чтобы их приложение продавалось в их магазине? В свое время Apple сказали: «…не пустим Flash». ОК, нехорошо ругались, плакали, нашли решение. Даже на Action-скрипте, который используют флешевики, можно писать приложение, которое потом перекомпилируется специальным компилятором, и его можно продавать в том же самом Apple Store. Разве это плохо? Почему Apple? Не знаю, как у вас, но в Штатах я хожу по улицам и вижу, мне кажется, больше людей с Apple-устройствами, чем с Android. Хотя мировая статистика показывает уже, наверно, другое. Почему? Потому что Apple очень жестко следит за процессом того, что попадает в продакшен, как выглядит приложение. Google, кстати, меньше следит, поэтому там, конечно, полная анархия. Я не считаю это политикой, но, скажем так, куда бедному крестьянину податься? Нативные приложения, которые написаны отдельно на Dalvik, отдельно на чем-нибудь для Apple, — это правильный подход, если вы себе его можете позволить. Например, если вы одиночка, который пишет какую-нибудь игру, вы считаете: это мой продукт, я сам решаю все, сам имплементирую, сам знаю и тот язык, и другой. Шикарно! Пишите нативно! Нативные приложения, как правило, будут всегда выигрывать по сравнению с приложениями общего плана, написанными на одном и том же языке и портированными как-то. Даже если это HTML и JavaScript. То есть вы сможете делать абсолютно точные компоненты, которые будут выглядеть нативно. Которые будут выглядеть так же, как все остальное на этом устройстве. Если вы себе это можете позволить.

Вернемся в корпоративный мир. Я — менеджер проекта. Мне сказали: начинаем внедряться на мобильники. Обычно выбирается какая-то пилотная платформа. Как правило, начинается или с iOS, или с Android. Мы выбрали какую-то, но я всегда думаю о следующем. Хорошо. Вот у меня есть эти же люди (если вы помните их имена: Ашот, Шреневаз, Петро). Я могу их послать на курсы, они выучат Objective-C или что-то такое. Хорошо. Вот мы задеплоимся, пойдем в продакшен. А мне через шесть месяцев нужно делать то же самое приложение на Android. Что, опять их брать тренировать? А они junior. Скажем так, сколько у меня денег в кармане? Сколько я могу нанять программистов, которые будут работать? Есть ли у меня бюджет на то, чтобы сделать две параллельные команды, которые будут делать параллельно и то и другое: одни — нативно для iOS, другие — нативно для Android? Если да — шикарно! Но тоже не очень шикарно. Это значит, у меня будет две базы кода, это значит, что багов у меня будет два набора, а не один. Релизы нужно будет делать, учитывая, что и там и здесь что-то поломалось.

Но крупные компании, которые могут себе это позволить, будут это делать! Наверно, это правильно. Что касается PhoneGap — это так называемые гибридные приложения. Они говорят: «пиши на HTML и JavaScript, есть у вас везде». На самом деле PhoneGap — это такое commercial, т. е. то, на чем Adobe хочет делать деньги. А на самом деле это все базировано на библиотеке, которая называется Cardolla. В свое время Adobe купила разработчиков Cardolla. То есть можно open source написать с использованием Cardolla-библиотеки, а можно использовать PhoneGap и их сервер для того, чтобы написать на JavaScript и HTML5, а потом отгрузить этот код к ним на сервер, и их сервер запакует ваше приложение, написанное на HTML и JS, под несколько платформ (не только iOS и Android) автоматически.

Но недостатками такого подхода является то, что люди говорят, что оно чуть-чуть медленнее, скроллинг будет работать не так, как нативно. То есть все-таки есть разница. Хотя это некое решение. Тот, кто не может себе позволить две отдельные команды, должен писать на одном языке, например на JS или HTML5 с какими-то библиотеками — с любыми. А потом отгрузить все на этот PhoneGap-сервер, сделать Build и отправить. Такое тоже возможно. А некоторые просто сидят, делают одно приложение и запускают у себя на устройстве с использованием… Но опять же здесь развилка. Либо я буду пользоваться отдельными фреймворками для мобильных, как вы сказали, jQuery mobile или Sencha touch например. Но тогда опять будет две версии приложений — одно для десктопов, второе — для мобильников. И надо определять, что человек зашел с мобильника. И есть там такое понятие User screen в HTML header и т. д., а их очень много. Или лучше выбрать другой подход — не пользоваться мобильными фреймворками, а писать все — писать одну базу кода HTML5 и JavaScript. Но есть такая техника — Responsible Design. То есть можно сделать так, что одно приложение будет написано и оно будет грузиться на разные экраны, будет хорошо работать, хорошо выглядеть. Там тоже есть какие-то нюансы. В общем, есть много подходов. Я не думаю, что какой-то выиграет. Если можете писать нативные приложения, пишите для каждой платформы. Не можете — извините!

В. Л.: Спасибо. Следующий вопрос в сторону бэкенда — базы данных NoSQL . Это новая тенденция, которая появилась. Сейчас все больше и больше о них слышно. Может, вы их тоже используете в своей компании? Как вы оцениваете их потенциал и если есть какие-то гибридные решения, то как их использовать?

Я. Ф.: Здесь я могу только одно. NoSQL базы данных занимают очень маленький сегмент у нас в Штатах. Может быть — 5%. Если взять все базы данных, которые используют, все-таки большая часть, подавляющая — это реляционные базы данных. И недостаток для предприятий, для приложений, типичных для Enterprise, — это то, что в них не поддерживается транзакционность, что часто нужно. С другой стороны, я лично ими не пользуюсь. Я смотрел несколько презентаций, читал о них, но не являюсь экспертом в этом деле совершенно. Поэтому мое мнение здесь не очень важное и весомое. У нас в компании есть парень (работает консультантом в крупнейшей финансовой компании), и он работает именно на MongoDB. Его взяли на проект, он ее изучил и пишет для них на MongoDB. Там приложение, где в основном отчеты — Reports. Они делают очень много отчетов. И вот там MongoDB показывает себя очень хорошо, хорошее быстродействие.

Здесь какая-то транзакционность особо не требуется. Опять же почему используется NoSQL? Можно хранить объекты в БД. Не требуется описание структур, как, например, в SQL требуется описание таблиц, колонок и т. д. И изменение структуры меняет все. Здесь этого не требуется. Поэтому я не могу сказать, что у меня есть хороший опыт с mixed solutions, когда используется и то и другое. Недавно был на презентации, где люди делают какие-то open source продукты, где они вообще пишут слой — ты пишешь SQL, язык запросов, но как движок они подставляют NoSQL. Ну OK, есть какие-то гибриды. Опять же я не могу много говорить об этом, так как я не специалист.

В. Л.: Хорошо, давайте в продолжение разговора о структурах данных поговорим о форматах их представления. Традиционный формат — это XML, но в последнее время XML стал постепенно вытесняться JSON . Как вы оцениваете перспективы этого противостояния?

Я. Ф.: Форматы данных. XML уходит, он тяжелый, нужно много писать тегов. И мы стремимся, чтобы количество байтов, которые бегут по проводам, было как можно меньше. Поэтому XML считаю уходящим, и писать приложение, где между клиентом и сервером будет бегать XML, непрактично. То есть его заменил JSON. JSON-формат заменил его почему? Потому что он не такой тяжелый, там нужно писать меньше тегов, а главное — он очень похож на формат написания JavaScript-объекта. Там почти все одинаково. То есть написать JS-объект и написать JSON. Поэтому сегодня на все браузеры (опять же говорю все, если этот браузер не старше двух лет) имеем парсинг JSON, ничего не нужно устанавливать. Поддерживается шикарно! Платформа, которая на backend, поддерживает генерацию и парсинг JSON! И .NET, и Java, и, скажем так, native Java — у них есть специальная поддержка JSON, там она уже внедрена. Не хочешь на этом — пожалуйста, Google сделала библиотеку JSON. JSON — самое популярное, и мы этого метода придерживаемся. Что касается того, чем люди пользуются.

Конечно, Google Protobuff  — это специальный формат, который компилируется, т. е. можно написать объекты на сервере и на клиенте, компилировать их в специальный формат и передавать данные с помощью этого protobuff. Но минусом является то, что нужно кое-что устанавливать для того, чтобы этот protobuff поддерживался на клиенте. Но мы остановились на JSON.

В. Л.: Насколько перспективным вы видите потенциал данного подхода?

Я. Ф.: Это было и в прошлом, и в настоящем — это так называемый Fatclient . Мы это используем постоянно внутри приложения, которое используется внутри Flash player. Написано на ActionSсript. То есть очень много бизнес-логики находится на клиенте. Что касается HTML- и JS- приложений — тут важную роль сыграл тот факт, что можно не перегружать всю страницу, — что называется AJAX. Позволяет больше иметь JavaScript-кода на клиенте, иметь логику там, не надо перегружать страницу, не надо перегружать state-состояние. При выполнении неких скриптов можно положить в какой-то объект промежуточные результаты, затем подтянуть новые данные; страница не перегружается, поэтому следующие скрипты могут использовать это state-состояние, что самое важное для таких rich frontend приложений. Это есть и будет. Вся бизнес-логика не уйдет на клиента. Это однозначно. Особенно на языках типа JS, где можно посмотреть исходники. А часть — да. Что касается еще одной предосторожности — валидация чего-то. Как правило, валидация в Java-приложениях, где есть HTML-код и JavaScript и что-то на backend, делается и там и здесь. Допустим, вы провалидировали данные на клиенте логикой на клиенте (форму заполнили, проверили), нажали кнопку Submit, и данные по проводам побежали на сервер. А может, их перехватили по дороге плохие дяди, плохие мальчики и девочки? Да, и на клиент уже пришло что-то другое. Все равно приходится писать валидацию на сервере тоже, чтобы обезопасить себя. То есть это будет существовать, я не хочу сказать, что это будет только так. Как раньше в 90-х годах самой популярной архитектурой была client-server. На клиенте все считалось, на сервере была база данных и все обрабатывалось. Не думаю, что это вернется в жесткой форме. Будет достаточное количество бизнес-логики на клиенте, но не вся.
Я желаю всего хорошего программистам из России, Украины, Белоруссии. Мы с ними хорошо работаем и дальше будем работать.

В. Л.: Спасибо вам за интервью.

8 декабря 2014 года Luxoft Training приглашает специалистов, пишущих на любых языках программирования, на онлайн-тренинг Якова Файна «Практическая разработка веб-приложений на JavaScript и AngularJS». Вы получите навыки разработки клиентских частей веб-приложений вне зависимости от используемой технологии серверной части. Обучение пройдет в среде, максимально приближенной к реальной.

Производство 3D-принтеров считается одной из самых отраслей в секторе ИТ. По оценке аналитиков агентства Gartner, в ближайшие годы эта индустрия вырастет ещё больше. Они считают, что по итогам текущего года будет продан 108 151 принтер, а в следующем году эта цифра вырастет до 217 350 штук (как видим, прогноз Gartner очень точный).

Дальше — больше. В течение каждого из следующих трёх лет объём продаж 3D-принтеров будет как минимум удваиваться, так что в 2018 году продажи вырастут до 2,3 миллиона штук.

«Как мы отмечали в прошлом году, рынок 3D-принтеров находится на рубеже кардинальных изменений, — говорит вице-президент по исследованиям Gartner Пит Басильер (Pete Basiliere). — Прошло 30 лет с момента изобретения этой технологии. На протяжении всего этого времени продажи росли крайне низкими темпами чуть более десятка процентов в год, в лучшем случае. Но в 2015 году намечается слом этой тенденции. Хотя наш прогноз может показаться радикальным, но имейте в виду, что 2,3 миллиона проданных устройств в 2018 году — это лишь малая часть потенциального рынка среди индивидуальных пользователей, коммерческих компаний и государственных организаций».

Рынок 3D-принтеров состоит из семи товарных категорий. Среди них наибольший объём продаж покажут расходные материалы для печати — пластик PLA, ABS и проч.

Наиболее популярными 3D-принтерами станут недорогие модели стоимостью менее $1000, в том числе существенную часть составят принтеры дешевле $500. Именно снижение стоимости станет главной причиной роста продаж, наряду с повышением качества оборудования и повсеместной доступностью товара во всех странах мира. Например, сейчас принтеры дешевле $1000 составляют всего 11,6% продаж среди устройств до $2500, но к 2018 году их доля вырастет до 28,1%.

Аналитики говорят, что на рынок выйдут новые фирмы, в том числе производители расходных материалов. Некоторые из них будут финансироваться через краудфандинговые кампании на Kickstarter и Indiegogo. Благодаря возросшей конкуренции снизится и стоимость товара. В качестве одного из драйверов роста Gartner называет упрощение подключения к компьютеру. Речь идёт о поддержке функции “plug-and-print”, то есть возможность печати сразу же после подключения устройства.

Microsoft прикладывает все силы, чтобы сделать Windows 10 самой лучшей операционной системой для настольных компьютеров. Ради этого компания даже не стесняется заимствовать лучшие функции у главного конкурента — Linux. В частности, Windows 10 содержит в своём составе полноценный пакетный менеджер. Таким образом, в Windows теперь возможно запустить командную оболочку и установить VLC, Firefox или тысячи других программ непосредственно из командной строки.

В настоящее время пакетный менеджер — одно из главных преимуществ Linux перед Windows и OS X. В то время как пользователям других операционных систем приходится запускать графический инсталлятор и многократно нажимать клавишу Next, под Linux достаточно всего лишь запустить команду вроде apt-get install vlc. Таким образом, процесс установки и обновления программ под Linux гораздо проще и приятнее.

Однако, разработчики Windows 10 намерены лишить конкурента этого преимущества. В состав этой операционной системы входит пакетный менеджер под названием OneGet. С его помощью устанавливаются программы командами вроде Find-Package VLC и Install-Package Firefox.

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

OneGet был представлен как часть пакета расширений Windows Management Framework 5.0 Preview для Windows 8.1 в сентябре 2014 года, но в Windows 10 он станет стандартным инструментом. Судя по всему, пакетный менеджер будет доступен через интерфейс PowerShell, известное средство для автоматизации действий в Windows, которое часто используется системными администраторами.

Остаётся открытым вопрос, как Microsoft будет популяризовать использование OneGet. Станет ли он чисто гиковским инструментом, о котором знают немногие, либо будет повсеместно применяться для установки программ и обновлений.

В Москве прошел финал ежегодного конкурса для технологических стартапов IBM SmartCamp. Победителем была признана компания Jelastic, резидент Кластера информационных технологий Фонда «Сколково», провайдер облачной платформы нового поколения, реализующей модель платформы как инфраструктуры (Platform-as-Infrastructure). Данная платформа позволяет значительно снизить затраты на развертывание и обслуживание корпоративных приложений в облаке. Решение Jelastic сочетает в себе гибкость предоставления облачных инфраструктур и простоту использования облачных платформ.

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

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

В мероприятиях IBM SmartCamp приняли участие: Кирилл Корнильев, генеральный директор IBM в России и СНГ; Игорь Богачев, вице-президент, исполнительный директор Кластера информационных технологий, Фонд «Сколково»; Олег Бяхов, директор по развитию бизнеса IBM в России и СНГ и ассоциированный партнер IBM Institute For Business Value; Алексей Аникин, руководитель направления стратегического развития бизнеса IBM в России и СНГ; Гари А. Фаулер, со-основатель и коммерческий директор GVA LaunchGurus и другие.

Кирилл Корнильев, генеральный директор IBM в России и СНГ:

«Феномен данных и облачные вычисления меняют бизнес и общество во всем мире. По оценкам аналитиков, к 2016 году более четверти всех приложений в мире будут доступны в облаке, а в настоящее время 85% нового программного обеспечения создается специально для облака, – говорит. – Я рад, что стартапы в полной мере задействуют новые технологические направления в своих проектах. Мне хотелось бы пожелать первому победителю российского IBM SmartCamp удачи в международном финале конкурса и дальнейших побед на пути развития своего проекта».

Игорь Богачев, вице-президент, исполнительный директор Кластера информационных технологий Фонда «Сколково»:

«Я хочу поблагодарить нашего ключевого партнера компанию IBM за то, что она проводит такие мероприятия в принципе, и особенно за то, что финал IBM SmartCamp прошел в Сколково. Роль партнеров Фонда — российских и международных компаний —  помощь в развитии стартапов, в том числе, менторская. Ценно, что опытом и знаниями делится с молодым компаниями такой крупный и значимый игрок IT-рынка, как IBM, важно, что команды могут получить грамотные рекомендации от экспертов мирового уровня».

IBM SmartCamp является частью программы IBM «Глобальный предприниматель”, запущенной в России в 2012 году. Участие в программе позволяет получить безвозмездный доступ к программному обеспечению и аппаратным средствам IBM, техническую поддержку проекта, консультации и содействие в продвижении готового продукта на рынок.

Подробнее см. на сайте Фонда «Сколково»

В течение всех трех дней работы московской конференция Cisco Connect (пройдет 18-20 ноября в московском Центре международной торговли) в зале «Амфитеатр» будет работать тематический поток «Инфраструктура корпоративной сети».

В этом году аналитическая компания Gartner в третий раз отнесла Cisco к числу лидеров в сегменте «Инфраструктура доступа проводных и беспроводных локальных сетей». Главными критериями при этом стали полнота стратегического видения Cisco и способность компании претворить свою стратегию в жизнь. С переходом к концепции Всеобъемлющего Интернета ожидается значительное увеличение количества подключенных к сети всевозможных предметов.

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

Первый день работы потока «Инфраструктура корпоративной сети» будет посвящен технологиям создания корпоративной локально-вычислительной сети (ЛВС) предприятия. Будут рассмотрены модели Converged Access, Instant Access и традиционная. Слушатели узнают о том, какие факторы влияют на выбор модели построения корпоративной сети, какие продукты лучше применять и какие преимущества дает каждая модель. Будут сделаны обзоры коммутаторов Cisco Catalyst для создания уровней доступа/распределения/ядра, представлены их отличительные функции и интеллектуальные сервисы, а также рассмотрены вопросы их позиционирования.

19 ноября речь пойдет о концепции Intelligent WAN (iWAN) для построения распределенных корпоративных сетей следующего поколения. Данный подход позволяет организациям снизить и оптимизировать свои расходы на ИТ, наиболее эффективно использовать инвестиции в маршрутизаторы Cisco и обеспечить масштабируемость для удаленных филиалов. Особое внимание будет уделено вопросам надежной доставки бизнес-приложений независимо от транспортной модели распределенной сети (MPLS VPN, Internet или гибридной WAN), интеллектуальной маршрутизации с применением новой версии протокола Performance Routing, а также возможностям мониторинга, контроля и оптимизации работы приложений в корпоративных распределенных сетях. Кроме того, слушатели узнают об основных тенденциях развития концепции программно-определяемых сетей (Software Defined Networking, SDN) и о примерах ее реализации в решениях для корпоративных сетей с использованием технологии APIC-EM. В заключение будут сделаны обзоры продуктовых линеек маршрутизаторов ISR G2 и ASR 1000. Кроме того, будет представлено новое поколение маршрутизаторов Cisco серий 4300/4400, рассмотрены их архитектура, технические возможности и сценарии применения.

В третий день конференции Cisco Connect будет сделан доклад по использованию протокола LISP (Locator/ID Separation Protocol) в кампусных сетях предприятий и архитектуры, обеспечивающей гибкость и масштабирование при адресации сетевых устройств. В завершение слушатели ознакомятся с  обзором оборудования Cisco в индустриальном исполнении и особенностями его применения при разработке сетевых решений в рамках концепции Интернета вещей (Internet of Things, IoT).

Зарегистрироваться для участия в Cisco Connect можно на сайте. Для участников образовательной программы Cisco Expo Learning Club разработаны специальные условия.

За год мощность DDoS-атак выросла в 4 раза, в соответствии с новым отчётом Q3 2014 State of the Internet от компании Akamai. Эта компания публикует ежеквартальные отчёты о глобальных тенденциях в интернете. За прошедшие месяцы с начала года ей пришлось защищать своих клиентов от атак, среди которых 17 штук превысило 100 гигабит/с, а самая серьёзная достигла 321 гигабита/с.

«Размер и мощность DDoS-атак в этом году превысила все возможные пределы», — говорит Джон Саммерс (John Summers), вице-президент подразделения безопасности в Akamai. Он добавил, что в 3-м квартале прошлого года не было зарегистрировано ни одной атаки больше 100 гигабит/с, тогда как в 3-м квартале текущего года таких было 6 штук.

В общей сложности, количество DDoS-атак в этом году выросло на 22%, а их мощность увеличилась на 366%, то есть более чем в четыре раза, если сравнивать два аналогичных квартала в этом и прошлом году.

Даже по сравнению с прошлым 2-м кварталом мощность DDoS-атак увеличилась очень значительно: на 80%. При этом злоумышленники используют более продвинутые техники. В частности, в 53% случаев применялись многовекторные атаки. Специалисты Akamai связывают это с большей доступностью программ с простым интерфейсом, с помощью которых запускается DDoS. Таким образом, этой деятельностью может заниматься больше людей. Ситуация усугубляется увеличением количества коммерческих заказов на такие атаки. К тому же, неблагоприятную обстановку создаёт наличие немалого количества уязвимых устройств, в том числе смартфонов, кабельных и DSL-модемов, планшетов и других гаджетов, принимающих участие в DDoS-атаках.

Что тебя больше всего бесит в мобильном приложении YouTube? Конечно, остановка воспроизведения при сворачивании приложения. А при возврате к приложению видео начинает снова подгружаться. При всей своей технологической навороченности и мультизадачности данный продукт по необъяснимым причинам до сих пор не умеет работать в фоне. Хватит это терпеть! Сегодня мы расскажем вам, как исправить сие досадное недоразумение.

Для устранения проблемы потребуется альтернативный плеер FREEdi YouTube Player, который доступен как для Android, так и для iOS. Интерфейс и логика работы приложения во многом схожи с нативным клиентом. Здесь есть все стандартные функции, включая возможность авторизации своим YouTube-аккаунтом, плюс продвинутая работа с плей-листами, таймер для отключения, подобие режима инкогнито, а также повтор воспроизведения.

Самое сладкое же начинается после попытки свернуть FREEdi YouTube Player. В области уведомлений появляется иконка приложения (в случае с Android), а воспроизведение продолжается в фоне. При открытии уведомлений отобразится привычный по «Google Музыке» и прочим музыкальным проигрывателям интерфейс. iOS-версия также воспроизводит ролики в фоне.

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

На конференции User Experience 2014 проверили жизнеспособность идеи Engagement на примерах российского рынка.

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

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

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

Другой вопрос, который волнует обе стороны – исполнителей и заказчиков «Как измерять вовлеченность». При этом на ум приходят различные метафоры. Например: «Измерять вовлеченность всё равно что есть слона: много работы, и ты не знаешь, с чего начать».

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

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

Некоторым приёмам создания такого свойства как вовлеченность научились участники мастер-класса «Истории, карты, кости и другие полезные приёмы из UX набора».

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

Все презентации конференции будут выложены на сайт.

Вслед за Google и Mozilla, компания Microsoft тоже анонсировала поддержку стандарта WebRTC в браузере. Ссылка на программные интерфейсы Object RTC для WebRTC появилась на странице IE среди опций, которые находятся в разработке.

Средствами WebRTC реализуется полноценный видеочат, который работает прямо в окне браузера, без каких-либо дополнительных плагинов или сторонних программ. Microsoft медлила с внедрением этой технологии, потому что она прямо конкурирует с сервисом Skype, который приносит немалый доход.

Microsoft сотрудничает с группой W3C ORTC Community Group. В создании стандарта принимает участие более 80 представителей разных компаний и организаций, в том числе разработчики браузеров, представители стартапов и эксперты в сфере коммуникаций. Microsoft строит работу на основе технологий Skype, Lync и прототипа Microsoft OpenTech.

В основе ORTC лежит использование нескольких протоколов, как описано в документах IETF RTCWEB Working Group, в том числе различных видеокодеков для масштабируемой и эффективной передачи видео и звука. Microsoft выступает за использование кодека H.264 для видео, а также нескольких кодеков для звука: Opus, G.722 и G.711. Компания стремится также сохранить совместимость реализации чата между разными браузераами и миллиардами других клиентов, включая VoIP-устройства на основе SIP, традиционными телефонами и системами видеоконференций.

За прогрессом в области разработки ORTC API для WebRTC предлагается следить на странице status.modern.IE.

Некоторые страны Европы давно выступают за введение «налога на Google», по которому поисковые системы должна платить деньги за использование интеллектуальной собственности правообладателей. Как известно, поисковики индексируют медийный и прочий контент и получают прибыль от этого. Некоторые считают такое поведение «паразитическим».

Теперь эта инициатива получила серьёзную поддержку: её поддержал новый комиссар по цифровым медиа и интернету Гюнтер Эттингер (Günther Oettinger, на фото). Это означает, что решение о «налоге на Google» может быть принято в Европарламенте и будет действовать для всех стран ЕС. Свою позицию Эттингер высказал в интервью немецкой газете Handelsblatt.

Категорически против «налогов» такого рода выступает Пиратская партия. Она напоминает, что в Германии в марте 2013 года принят новый закон о защите копирайта, который издатели изначально позиционировали как «налог на Google». Но реальная практика его применения привела к тому, что «налог» в пользу правообладателей через организацию VG Media платят все аггрегаторы новостей кроме Google. Непонятно, что изменится, если немецкий закон распространят на всю Европу.

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

«Если такое произойдёт, то это станет худшим началом для долгожданной реформы европейского законодательства о защите интеллектуальной собственности, — пишет Юлия Реда (Julia Reda), представитель Пиратской партии в Европарламенте. — Я обратилась к Еврокомиссии с запросом, как они рассматривают влияние германского закона о копирайте на доминирующие позиции Google на рынке и планируют ли они принятие других похожих законов».