Наверх ▲

Microsoft Ajax Minifier (Автоматическая оптимизация JavaScript and CSS для веб сайтов высокой производительности)

Евгений Чигиринский Евгений Чигиринский Руководитель команды разработчиков Microsoft.


Евгений Чигиринский: Добрый день, меня зовут Евгений Чигиринский, я работаю в Microsoft. Расскажу о том, что такое минификация и зачем она нужна.

Что такое минификация?

Минификация – это рефакторинг вашего CSS и JavaScript. Суть простая – размер файла меньше, функциональность та же самая. Весь фокус в том, как сделать размер файла меньше и при этом не "убить" функциональность. В случае с JavaScript и CSS это сделать элементарно. Естественно, на этом экономится трафик, потому что для клиентов, которые приходят на ваш сайт, время загрузки страницы уменьшается.

Конечно, JavaScript и CSS кэшируются браузером, все это знают. Но если при выполнении call start кто-то приходит на вашу страничку в первый раз или если вам нужно часто менять ваш JavaScript и CSS... К сожалению, некоторые сайты работают по принципу сборки. Например, MSN – это портал.

Мы пытаемся давать программистам разрабатывать модули независимо друг от друга. Например, модуль погоды, модуль новостей, модуль Facebook или HotMail. Каждый их таких модулей разрабатывается отдельно. Каждый из них имеет свой JavaScript и CSS. Потом мы их все собираем. Мы пишем специальные инструменты для этого процесса. Мы заинтересованы в том, чтобы получившиеся сборки были оптимальны и минимизированы.

На что стоит обращать внимание, когда минифицируют CSS и особенно JavaScript?

Конечно, читаемость кода тут же уменьшается. Если у вас есть хорошо написанный, структурированный, понятный JavaScript, там много комментариев, пробелы – это все первые кандидаты на то, чтобы их убрать, когда JavaScript-файл вывешивается на сайт. Естественно, если вы будете делать это своим исходным кодом и так его хранить, код будет, мягко говоря, нечитаем. Это довольно стандартная проблема, с которой все сталкиваются.

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

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

Что надо помнить еще, когда минифицируется JavaScript и CSS?

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

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

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

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

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

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

Приведу пример. На сайтах amazon.com файлы JavaScript "весят" порядка 120-140 килобайт. После минификации размер уменьшается вполовину. Это достаточно хороший выигрыш по производительности. Примерно то же самое с CSS.

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

Интересная проблема для JavaScript – это использование имен переменных. Конечно, при программировании всем хочется называть переменную так, чтобы, глядя на нее, все поняли смысл, что этой переменной нужно. Получается, если вы используете нотации, принятые в C++, то имя переменной будет достаточно длинным. Оно используется 50-60 раз в вашем коде. Естественно, размер файла от этого увеличивается.

Опять же, все это достаточно элементарно. Мы исследовали много JavaScript-файлов, которые мы смогли получить. Как ни странно, разработчики почему-то предпочитают крайности: или их переменные – по 25-35 символов на каждую, или они делают имя переменной в одну букву (i, j, x, y, i1, i2). Читать такой код – удовольствие еще то.

К примеру, к разработчику приходит код, написанный кем-то год назад, и у него задача – за день быстро разобраться, что это за код, и как-нибудь быстро его оптимизировать. Он приходит в ужас от того, что видит.

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

Выражения для отладчика (англ. Debugger statements). Конечно, все хотят отлаживать свой код, все в него засовывают выражения для отладки. Естественно, многие из них (особенно там, где def-процессы не налажены) попадают на финальный сайт. Естественно, их надо убирать. Иногда это может быть достаточно трудной, кропотливой работой. Для этого, на мой взгляд, лучше использовать какие-то инструменты. Но, опять же, не у всех есть возможность или желание.

Еще одна, довольно распространенная проблема, с которой мы столкнулись. Очень много инструментов разработки, которые запоминаются в простом Unicode (UTF-16, например). Это заканчивается тем, что разработчик просто пишет массу кода, сохраняет его в этом Unicode и так не глядя выкладывает его на сайт. В результате его просто можно уменьшить в 2 раза, переведя на ASCII.

Если вам нужно делать локализацию (в Microsoft эта проблема стоит довольно остро – постоянно требуются иероглифы для японских или китайских символов), можно использовать UTF. Тогда у вас будет оптимально. Всего по байту на каждый ASCII символ, но если вам нужен какой-то Unicode, тогда UTF-8 может вам помочь (он существует специально для этих символов). Microsoft тоже грешен: вы создадите новый JavaScript-файл в Visual Stidio, будет использоваться Unicode. Я до сих пор не понимаю, почему это сделано, мы очень много говорили об этом с людьми из команды Visual Studio. Надеюсь, они это исправят.

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

Многие разработчики C++ или C-Sharp начинают осваивать JavaScript. Это все, конечно, хорошо. Они очень хорошие разработчики. Это, опять же, внутренняя проблема Microsoft: часто разработчики делают приложения типа Windows или Visual Studio, а потом приходят в веб-разработку, начинают писать JavaScript,  и у них начинаются очень интересные проблемы.

К примеру, на слайде 5 выражений, которые выглядят абсолютно элементарно. Новый объект, новый массив, просто присвоение значения (переменной "i" присвоено значение 10 миллионов). Каждое из этих выражений можно минифицировать. В каком-то случае вы уберете пару-тройку байт, в каком-то – десяток байт. Вот минификация.

Если рассмотреть, то это известно абсолютно всем. Все, кто начинал программировать, делали это много-много раз. Но сколько людей об этом забыло.

Мой любимый пример – последний. Как можно 10 тысяч записать всего тремя байтами? Сколько раз у программистов случается "у var i equals 1000", например? Даже с тысячей это – 1 и 3 минус байт. Сколько таких выражений встречается в JavaScript-файле? Очень много.

Объявление и инициализация переменных

Опять же, здесь очень много возможностей для сокращения. Те, кто использовал C++ и C-Sharp, научены, что каждая отдельная переменная должна объявляться отдельно, весь код надо разделять для легкой читаемости. Такие выражения встречаются везде.

Минификация элементарна. Хотя бы с первого блока вы убираете слово var трижды. Этот пример – 12 байт на месте. Все это мелочи, если у вас код JavaScript на 3-4 функции. Если у вас JavaScript-файл размером 140 килобайт, то вы начинаете учитывать такие вещи, потому что это реально работает.

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

Switch-блок

Опять же, один из моих любимых примеров. Вот обычный switch-блок. Если у вас значение “a”, то ничего не делать, если значение “b” – чему-то присвоить, по умолчанию – уйти, по значению “f” – присвоить “f”. Опять же, все это элементарные вещи. Ничего сложного. Отсюда можно убрать примерно треть.

Самый простой пример: вспомним, как работает switch-блок. Все это прекрасно знают. Можно, например, убрать пустой “default”. Можно убрать пустой case “a”. Можно убрать последний "break", потому что он не приносит ничего функционального. Но все это лишние байты, которые вам не нужны.

К сожалению, чем JavaScript становится сложнее, тем больше надо смотреть, что вы делаете, иначе вы нарушите функциональность. Например, стоит посмотреть, нет у вас умолчания или по умолчанию существует какая-то функциональность (в данном случае "default" у меня пуст - я просто выхожу по нему). В данном случае в умолчании ничего не было. Просто кто-то сделал копирование и вставку, поставил пустой блок “finally”, и в таком виде это все путешествовало с незапамятных времен.

Если есть блок “catch”, блок “finally” можно убрать (если он пустой). Порядка десяти байт экономится на удалении пустого блока. Помните: если “catch” нет, и вы удалите “finally”, то получится ошибка. Но такого кода очень много (даже в jQuery, насколько я помню, он есть).

Вызовы функций и блоков кода

Здесь, к сожалению, мы пойдем по более сложному пути. Естественно, повышаются риски нарушить вашу функциональность.

Например, у вас есть функция с массой параметров, которая была разработана в незапамятные времена и потом переделана много раз. В данный момент вы хотите показать параметр “a”. “A” – это просто какое-то выражение, “B” – это вызов функции, “C” – еще одно выражение.

Отсюда можно выбросить очень много. Например, все ненужные параметры. JavaScript не компилятор, он не указывает, используются ли параметры. Все эти параметры не нужны. В данном примере экономим 8 байт сразу же.

“If (A) B()” – это очень интересное выражение, встречается везде. Мы исследовали порядка 4 или 5 больших библиотек. В каждой из них мы смогли сбросить порядка 5-6 килобайт только на этом вызове, если я не ошибаюсь. “If (A) B()” транслируется просто “if equals “B”.

По функциональности это абсолютно одно и то же. Но в данном случае читабельность кода сильно уменьшается. Поэтому каждый раз, когда мы делаем такие вещи, мы думаем: «Наше выражение “A” действительно достаточно простое?»

Последнее тоже достаточно просто. Вместо “If (C) return”, если ваша функция не возвращает ничего, можно сделать просто “C”. Не знаю почему, это очень распространенный паттерн. Очень хорошо читается. Минус еще 12 байт.

Минификация CSS 

Теперь я хочу перейти к минификации CSS. CSS, Cascading Style Sheets – гораздо менее логичный язык. На мой взгляд, это совсем не язык. Он не определяет, как функциональность обеспечивается по языку. Но что-то из него убрать все равно можно.

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

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

Оказалось, что мы можем сократить размер файла, если исследуем весь CSS на повторяющиеся селекторы. Мы убираем те, которые повторяются, оставляя один (обычно самый последний). Это в том случае, если и селектор, и property внутри него абсолютно одни и те же.

Самое интересное в CSS начинается, когда вы можете сжимать селекторы, которые определены по-разному. Или, например, это один и тот же селектор, но с разными свойствами, которые разбросаны по всему коду. Такое встречается сплошь и рядом. Кто-то определил селектор в CSS. У него там синий цвет, там граница (англ. margin), отступ (англ. padding) – все замечательно. Потом внизу видим: «Давайте я все же поменяю на красный». Естественно, он забыл, что менял свойство на «синий», и влепил еще один в самом конце. «Я хочу, чтобы он был синий». Естественно, это и лишнее определение селектора, и лишние байты.

Еще один момент: возможно удаление ненужных свойств из определений отступа, цвета, длины и удаление точки с запятой перед открытием селектора. Это очень распространенный случай. Ставить знак “;” перед закрывающей скобкой селектора не нужно. В коде она присутствует практически всегда. Кто-то добавляет, убирает – конечно, неудобно все время об этом помнить. Но если у вас очень много селекторов в коде, то с каждого селектора можно убрать один байт – это будет достаточно много.

На слайдах несколько примеров того, как вы можете сжать селектор. Например, один и тот же "foo". Просто у него определено 3 свойства в начале и 4-е в конце. Это то, о чем я говорил с самого начала. Встречается сплошь и рядом.

Что можно сделать? Во-первых, цвет. Красный указан после синего, он будет использован в итоге. Синий не будет играть никакой роли, его можно просто выкинуть. У "margin" можно выкинуть две последние цифры (если они повторяются, будет абсолютно то же самое). Два определения селектора можно "схлопнуть" в одно.

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

Сжатие селекторов с различными именами – тут все немного посложнее. Можно очень хорошо сэкономить, если много селекторов используют одни и те же свойства с одними и теми же значениями. Например, у меня есть “bar”, у него синий цвет, но "margin" и "padding" – оба нули. Также есть “foo”, у которого все то же самое, но цвет красный. Это можно очень хорошо сжать.

Вам не надо определять "margin" и "padding" во второй раз. Каждое из этих выражений занимает порядка 9 байт. 20 байт вы выигрываете на таком простейшем рефакторинге.

Сжатие значений

В стандарте языка CSS очень многие вещи можно не писать, применяя по умолчанию. Все 3 выражения здесь можно сжать. Пиксели по умолчанию: если вы просто укажете число, это будет то же самое. Px – 2 байта. Margin – если одно число на все 4 границы будет одинаковым, то абсолютно то же самое.

Цвет

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

Выводы

О них я хотел бы поговорить более подробно. Минификация позволяет очень сильно уменьшить файл. С помощью минификации мы уменьшаем размер файла где-то на 40-50 %. Мы думали, что наш JavaScript или CSS написаны плохо, мы не были так уверены в себе. Мы написали инструменты, которые делают это автоматически. Эта и еще куча других минификаций (на самом деле, здесь я привел очевидные, которые можно использовать в коде, программируя вручную).

Если вы используете инструменты, которые проверяют код парсерами, выделяют его зависимости и знают, как JavaScript и CSS устроены внутри, то можно выделить гораздо больше закономерностей. Мы сжали наши файлы где-то на 40-50 %. Но мы сжали и файлы, которые разработаны открытым сообществом, примерно в такой же степени.

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

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

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

Один из инструментов, которые мы разработали, называется Microsoft Ajax Minifier. Это, к сожалению, не сервис. Это просто инструмент. Он существует только как решение с открытым исходным кодом под Windows. Его, конечно, можно перекомпилировать под Mono, под что угодно. Он написан на C-Sharp. Но он дает очень хорошие результаты, за счет использования массу алгоритмов сжатия.

Более того, это один из немногих инструментов, который сжимает не только JavaScript, но и CSS. Обычно минификаторы концентрируются на чем-то одном – или на CSS, или на JavaScript. Но я даже не знаю инструмента, который хорошо сжимает CSS. Для JavaScript у Yahoo есть хороший минификатор, у Google есть Closure.

Это – то, что мы внесли в общую копилку.

Собственно, это все. Такая простая и легкая презентация. Если есть вопросы – пожалуйста, задавайте.

Вопросы и ответы

Вопрос из зала:
Иногда при разработке (особенно под старые версии браузеров) приходится использовать хаки. Как он работает с хаками? Например, для Interner Explorer 6 очень я часто использую первое подчеркивание.
Евгений Чигиринский:
Вы имеете в виду, как мы работаем или как работает инструмент?
Вопрос из зала:
Как работает инструмент. Скажем, если я это запущу, не потеряю ли я этого.
Евгений Чигиринский:
"Инструмент" их понимает. Используя "command line up", в инструменте можно задать то, какие хаки он может распознавать. Я понимаю, что мы делаем Internet Explorer, но поверьте, что даже внутри Microsoft не все счастливы от того, как его делают. Ничего не могу сказать, он становится гораздо лучше. Но, к примеру, Internet Explorer 6 – это… Но суть не в том.
Суть в том, что в нем используется очень много хаков, и инструмент распознает их. Вы можете задать несколько режимов. Или он может просто работать как валидатор и "говорить", что хаки использовать нельзя. Или он может пропускать эти хаки, и некоторые из них он может даже оптимизировать.
Например, мы сделали специальный хак: классический способ определение в Internet Explorer версии браузера – через комментарий. Это настолько часто используемый хак, что мы сделали специальную поддержку для него в Ajax Mini. Но это, скорее, исключение из правил.
Ajax Mini может работать и как валидатор. У него есть специальный режим. Вы можете запустить его как "проверяльщик" вашего JavaScript. Если вы укажете, что «я не хочу никаких хаков в JavaScript», он выдаст вам ошибку. Если вы используете его как часть сборки, то это очень хорошо помогает.
Вопрос из зала:
Вы очень классно порекомендовали убирать единицу измерения у границы, у ширины, еще у чего-то. Проблема в том, что это работает только в IE. Если не указывать размерность, то во всех остальных браузерах это правило просто не сработает. Стоило про это упомянуть.
Евгений Чигиринский:
Конечно. Если вы запустите сам минификатор как инструмент… Некоторые из этих примеров специфичны, потому что, как бы мы ни крутились, в Штатах Internet Explorer 6, к моему сожалению, остается самым распространенным браузером. Как бы мы ни пытались, мы ничего с этим сделать не можем. К сожалению, мы не можем влиять на пользователей так, как нам бы хотелось. Если бы вы спросили меня, я бы первым запретил использование Internet Explorer 6. Кроме головной боли, он нам абсолютно ничего не приносит. Некоторые из примеров работают только для IE, некоторые – нет.
Вопрос из зала:
Думали ли вы об обратной связи кода, который получился после минификации, с оригинальным через какие-то внешние хранилища? Поскольку код получается реально плохо читаемым, то, получив ошибку в нужной строке, хотелось бы иногда вернуться к оригиналу через какое-то внешние файлы и так далее.
Евгений Чигиринский:
Да, такая проблема, безусловно, существует. Если у вас проблема на реальном сайте, и вы хотите посмотреть, что там, приходится просматривать минифицированный код. Читать его крайне сложно, тут я абсолютно согласен. Мы с этим сталкиваемся все время.
Как мы это решаем. К примеру, у нашего минификатора есть разные режимы. Вы можете минифицировать все. Вы можете сказать ему, чтобы он минифицировал, например, логику, но не убирал, например, переносы строк (англ. line breaks) или комментарии. Мы используем его в таком режиме, чтобы доводить сайты до отладки и даже выпускаем их немного на продакшн (не совсем минимизированно), чтобы убедиться, что все нормально. Когда мы точно знаем, что все нормально, тогда мы перекомпилируем в полной минимизации.
Вопрос из зала:
Файла изменений, по которому можно вернуться из продакшна к оригинальному, у вас нет?
Евгений Чигиринский:
Нет. Мы просто берем один файл и минимизируем его в другой.
Вопрос из зала:
Вы делаете его в открытом доступе?
Евгений Чигиринский:
Да, мы делаем его как Open Source. Мы можем рассмотреть любое предложение. Я один из тех разработчиков, кто делал инструмент, мимо меня оно не пройдет.
Вопрос из зала:
Примерная разница между просто gzip и gzip после минификации – по общему результату, сколько там процентов?
Евгений Чигиринский:
Это очень зависит от файла. Могу сказать, к примеру, для jQuery. Разница между gzip минифицированного файла и Ajax Mini получалась где-то 2 %. Но если вы берете gzip, JQuery оригинального и, к примеру, Ajax Mini, то будет разница порядка 10-12 %. Но иногда gzip даст вам лучший результат и без всякой минификации. Это зависит от того, насколько структурированно у вас написан файл.
Вопрос из зала:
Интересует ваше мнение по поводу обфускации CSS. Насколько это актуально, какие решения вы знаете? В частности, как поддержать связку с HTML-разметкой и в дальнейшем с JavaScript.
Евгений Чигиринский:
Вопрос хороший. Мы рассматривали эту проблему и решили, что для нас заниматься ею было бы слишком дорого. Мы, конечно, можем написать инструменты, которые обеспечивают вам переход из HTML к CSS, чтобы понять все связи из HTML к CSS, сделать обфускацию. С точки зрения производительности это послужит очень хорошим примером, потому что вы можете сократить еще больше. Но когда мы посмотрели на стоимость разработки таких инструментов, выяснилось, что для нас это слишком дорого. Мы отказались от этого. В Microsoft есть отдел, который занимается Visual Studio (мы его называем Developer Division – те, кто делает всю Visual Studio). Может, они посмотрят на это, как на часть платформы. Мы решили этим не заниматься. Просто дорого.
Вопрос из зала:
Вы рассматривали возможность встраивания этого инструмента непосредственно в веб-сервер (скажем, в IIS), чтобы минимизировать "на лету"?
Евгений Чигиринский:
Да, рассматривали и рассматриваем сейчас. Сейчас инструмент существует, как ни странно, во всех ипостасях, кроме веб-сервера. Например, есть DLL. Если кто-то хочет писать программы против этого инструмента и вызывать его как SDK или как API, вы можете это делать. Мы даже сделали MSBuild Tast на это инструменте. Если кто-то хочет его встроить как часть сборки, это можно сделать элементарно. Единственное, что мы пока не сделали, это веб-сервер. На самом деле, это в планах. Мы хотим это сделать, потому что у нас очень много запросов на такую реализацию. Это будет абсолютно элементарно. Делать это – полдня работы, учитывая то, что у нас есть собственный SDK. Ответ, к сожалению, очень простой и неутешительный – не доходят руки.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Юрий Востриков

Юрий Востриков

Один из ведущих разработчиков Mail.Ru.

Юрий Востриков (Mail.Ru) рассказывает о Tarantool/Silverbox - высокопроизводительной базе данных в оперативной памяти.

Владимир Бобриков

Владимир Бобриков

Руководитель НИОКР-а (Imhonet).

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

Илья Космодемьянский

Илья Космодемьянский

CEO и консультант в компании Data Egret, специалист по базам данных PostgreSQL, Oracle, DB2.

Илья Космодемьянский говорит о резервном копировании (Backup) и восстановлении (Recovery) в самых разных системах.