Слайды.

Слайды

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

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

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

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

Смотрите в полноэкранном режиме.

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

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

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

В предыдущем абзаце я нарочно ввел термин “инженер-программист”. Как-то получается так, что программист — это не обязательно инженер. Даже из определения Википедии следует, что инженер — это в первую очередь проектировщик. Это тот, кто создает, т.е. проектирует системы. А в практике программирования проектирование нужно не всегда. Иногда достаточно кодирования: используя данный набор технологий, слепить что-то работающее. Типичный пример — стадо корпоративных или маркетинговых сайтов на джумлах, ворпрессах, друпалах и т.д. Это уровень техника, не инженера. Это уровень среднего образования. И работать техником можно даже после окончания курсов какого-либо языка программирования, крепкая теоретическая база там не нужна.

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

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

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

Первый уровень из CS (computer science) — Специальная база. Это стартовая площадка для любого программиста по четырем фронтам:

• арифметические основы ЭВМ (системы счисления и операции с числами, логические операции);

• физические основы ЭВМ (полупроводники, транзисторы, логические элементы, схемы, интегральные микросхемы);

• теория алгоритмов (алгоритмы и структуры данных; сложность, эффективность; способы представления информации в памяти);

• языки программирования (задача и понятие ЯП, уровни, типы языков, абстракция, уровни абстракции, трансляция/компиляция, шаблоны, принципы, парадигмы — обзор).

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

Уровнем выше располагаются дисциплины, которые являются базовыми именно в программировании. По-этому я назвал этот уровень Основы. В него входят:

• архитектура ЭВМ (процессоры, микроархитектура, память, шины, ввод/вывод);

• обработка информации (теория информации, статистика, модели, поиск данных, лингвистические аспекты, обработка информации средствами табличных процессоров);

• основы C/C++ (базовые свойства языка, синтаксис, указатели, ввод/вывод, массивы, основы STL).

Следом за Основами идет Уровень 1. Это первый прикладной уровень, и особо нетерпеливые могут начать коммерческую практику, овладев этим уровнем. Он включает 5 дисциплин:

• основы ASM (развитие архитектуры ЭВМ в направлении программирования, написание простейших драйверов и алгоритмов, ассемблерные вставки в C/C++);

• C/C++ (ООП, разработка прикладных приложений, библиотеки, WinAPI, make utils, параллельное программирование).

• операционные системы (архитектура ОС, процессы, межпроцессное взаимодействие, потоки, планирование, работы с памятью и переферией, POSIX-системы);

• системный анализ (предметная область, бизнес-процессы, потоки, диаграммы, принципы и теория системного анализа);

• базы данных (теория множеств, виды СУБД, реляционные СУБД, модели данных, SQL, конкретные БД).

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

Уровень 2 включает:

• разработку ПО (жизненный цикл ПО, этапы разработки, основы ведения программных проектов, инструменты);

• анализ данных (Data Mining, OLAP, машинное обучение, нейронные сети, ИИ);

• компьютерные сети (по уровням стеков TCP/IP и/или ISO/OSI “от и до”, протоколы, сетевое программирование на C/C++);

• языки программирования с управляемым кодом (управляемый код, виртуальные машины, сборщики мусора, юнит-тестирование, собственно практика на C# или Java);

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

• разработка UI и юзабилити (принципы построения интерфейсов пользователя);

• управление командами и проектами (методологии разработки и другие вопросы управления);

• тестирование ПО (обзорно: виды тестирования, инструменты);

• веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);

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

• интерпретируемые языки программирования (особенности, основы по двум-трем языкам, практика по одному-двум языкам: JS, PHP, Python, Ruby).

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

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

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

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

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

Листинг /etc/nginx/sites-available/example.com.conf:

map $http_cookie $isDevHack {
    default "";
    ~DEVELOPER_SECRET_COOKIE=10101 "/non-existed-location";
}

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;

    access_log /var/log/nginx/example.com.access_log;
    error_log /var/log/nginx/example.com.error_log;

    root /home/example.com/htdocs/;
    index index.html index.php;
    client_max_body_size 15M;

    location /phpmyadmin/ {
        root /usr/share/;
        index index.php index.html index.htm;
        location ~ ^/mysql-pma/(.+\.php)$ {
            try_files $uri =404;
            root /usr/share/;
            fastcgi_pass unix:/tmp/example.com.pool.socket;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include /etc/nginx/fastcgi_params;
        }
    }

    # Redirect www to no-www
    if ($host = 'www.example.com') {
        rewrite ^/(.*)$ http://example.com/$1 permanent;
    }

    # Only requests to our Host are allowed
    if ($host !~ ^(example.com|www.example.com)$ ) {
        return 444;
    }

    # Locations
    location / {
        if (-f "$isDevHack/home/example.com/maintenance") {
            return 503;
        }
        try_files $uri $uri/ /index.php?$args;
    }

    # RockMongo
    location /rockmongo/ {
        root /home/example.com/;
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ ^/rockmongo/.*\.php {
        root /home/example.com/;
        fastcgi_pass unix:/tmp/example.com.pool.socket;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~ \.(php|phtml) {
        fastcgi_pass unix:/tmp/example.com.pool.socket;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # APC status page
    location = /apc-status.php {
        fastcgi_pass unix:/tmp/example.com.pool.socket;
        fastcgi_param SCRIPT_FILENAME /home/example.com/apc.php;
        include fastcgi_params;
    }

    # Memcached status page
    location = /memcached-status.php {
        fastcgi_pass unix:/tmp/example.com.pool.socket;
        fastcgi_param SCRIPT_FILENAME /home/example.com/memcached.php;
        include fastcgi_params;
    }

    location ~ \.(tpl|xml|log)$ {
        deny all;
    }

    # Errors
    error_page 503 @maintenance;
    location @maintenance {
        rewrite ^(.*)$ /maintenance-mode.html break;
    }

    # SSL
    ssl_certificate /etc/nginx/ssl/example.com.chained.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_session_timeout 5m;
    ssl_protocols SSLv2 SSLv3 TLSv1;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
}

Стоит отметить то, что исполняемый код сайта (PHP) на целевом сервере работает по схема схема nginx—php-fpm, а выбор файла — через try_files. Так же подчеркиваю, что требуется проверка, является ли пользователь разработчиком. Эти два фактора вместе отметали простые классические решения этой проблемы (в Гугле их масса, например).

Самое простое решение без проверки (разработчик или нет) заключается в том, что  бы проверять наличие специального файла в начале до проверки других условий. Это можно сделать с помощью try_files, подставив файл страницы с ошибкой первым в очереди. Но помимо того неудобства, что требуется добавлять/удалять файл в исходниках сайта (что не очень хорошо при заливке исходников через системы контроля версий), этот вариант просто не работает в сочетании с секциями if, которые появятся для добавления проверки «разработчик или нет». После входа в любую секцию if try_files ведет себя своеобразно и неправильно резолвит полные пути к файлам; источник проблемы описан тут.

Кстати, а по какому признаку мы будем проверять, является ли пользователь разработчиком? Ну, вариантов достаточно много. Самый удобный и популярный вариант — по наличию «специальной» cookie. Еще один популярный вариант — по IP. На какой фактор полагаться, большой разницы нет. В любом случае требуется проверка значения некоторой переменной, и осуществить эту проверку можно только с помощью секции if.

Резюмируя описанное выше: мы не можем делать проверку на наличие файла страницы обслуживания вместе с проверкой дополнительного фактора «разработчик или нет», используя try_files. Значит, проверку на наличие файла можно делать только с помощью if. В nginx if не может принимать два условия. Но эта проблема решается. Казалось бы, что цель достигнута. Проверяем 2 фактора: наличие файла и факт того, что пользователь — разработчик. Но такие проверки обязательно требуют входа хотя бы в один if. И тут опять фэйл: после входа в любой if try_files ведет себя своеобразно и неправильно резолвит полные пути к файлам после входа в секцию if; источник проблемы описан тут.

Короче, все довольно запутано и мутно. После нескольких часов мучительного подбора вариантов решение таки было найдено. Я выбрал способ проверки разработчика по cookie. Схема вышла очень простой. Один из if-ов был заменен map-ом, который работает нормально с try_files. А объединение условий (наличия файла и cookie) было реализовано через подмену пути к этому файлу. Т.е. в случае, когда пользователь — разработчик, мы просто портим имя файла, наличие которого свидетельствует о включенном режиме обслуживания.

Итоговая конфигурация.

В секции http (вне секций server) прописываем проверку «разработчик или нет». Она будет распространяться на все сайты в случае виртуального хостинга. В данном случае, если у пользователя установлена cookie DEVELOPER_SECRET_COOKIE со значением 1100110101, то пользователь будет признан разработчиком.

map $http_cookie $isDevHack {
    default "";
    ~DEVELOPER_SECRET_COOKIE=1100110101 "/non-existed-location";
}

В соответствующей секции server объявляем собственный обработчик ошибки 503, которая будет использована для индикации режима обслуживания:

error_page 503 @maintenance;
location @maintenance {
    rewrite ^(.*)$ /maintenance-mode.html break;
}

В данном случае подразумевается, что страница, которую нужно показать в случае работы в режиме обслуживания, находится в файле maintenance-mode.html, который лежит в корне сайта ($document_root данной секции server).

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

if (-f "$isDevHack/home/site_root/maintenance") {
    return 503;
}

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

Пример конфига nginx целиком для сайта example.com.

Создается скрипт, запуск которого можно поместить в cron (расписание зависит от ситуации и важности сайта). Код:

Самая известная в определенных кругах версия Internet Explorer 6 вышла в августе 2001 года перед выпуском Windows XP. Она стала эпохальной. Дальнейшая активная разработка браузера фактически прекратилась.

Только в 2006 вышла версия Internet Explorer 7 для Vista, которая наконец-то включила в себя то, что давно стало стандартом во всех современных браузерах — вкладки. Кроме того, были исправлены многие ошибки 6-й версии, добавлена поддержка некоторых новых стандартов.

За эти годы (перерыв между версиями 6 и 7) Microsoft почти потеряла рынок. Компанию не интересовали ни проблемы пользователей, ни разработчиков. Опомнились они только тогда, когда ситуация стала угрожающей. Версия Internet Explorer 8, которая уже могла хоть как-то претендовать на конкуренцию в современных условиях, вышла только в марте 2009. Пожалуй, это был ответ на выпуск Google Chrome (бета в сентябре 2008). В Microsoft вернулся интерес к рынку браузеров.

Почему же вначале 2000-х разработка Internet Explorer была заброшена? О чем думали в Microsoft, когда делали такой перерыв (5 лет!) между выпусками версий в такой конкурентной и динамичной области, как Интернет, где все меняется с огромной скоростью?

Сомнений нет — это стратегические решения. Ведь денежный вопрос в Microsoft точно не стоял. А профессиональный уровень менеджеров и руководителей компании не вызывает сомнений. Стратегия 90-х основывалась на продажах Windows и привязке разработчиков и пользователей к Windows API. Подробнее об этом написано у Джоэла Спольски. Для Веба API операционной системы не имел никакого значения. Привязки в конкретной ОС не было. Следовательно, Microsoft потеряла заинтересованность в развитии своего браузера. Ведь изначально он служил целям популяризации и привязки пользователей к Windows. А в 2000-х эффект стал обратным — Веб стал отвязывать пользователей, привязанных с таким трудом к Microsoft.

Так как ускорять такое развитие событий Microsoft было не выгодно, разработка браузера была заброшена, а инициатива — отдана конкурентам. В 2006-м Microsoft пришлось доработать свой браузер для Vista, так как версия 6 к тому времени перестала нормально решать задачу пользователя Windows — серфинг в Сети. Поэтому версия 7 не сделала больших шагов вперед, если не считать исправления ошибок.

Более важным был выход следующей версии — Internet Explorer 8 (март 2009). Microsoft сменила стратегию — браузер стал ближе к разработчикам. В последних версиях IE наблюдаются четкие попытки достичь нормального современного уровня по тем фронтам, где Explorer отстал наиболее значительно. Начались постоянные компании по продвижению IE, в том числе и среди разработчиков веб-приложений. Участился выпуск новых версий.

Что заставило Microsoft изменить стратегию и вновь взяться за развитие своего браузера? Начало новой эры развития Интернета! Я об этом писал раньше. Сейчас Google заставляет шевелиться Microsoft. На данный момент, из-за опозданий последней, Google одержал победу в битве на поле браузеров. Но война еще не окончена. И не последнее слово в ней будет за Windows 8, в состав которой войдет Internet Explorer 10.

Посмотрите на

Но самое важное то, что они намекают на скорый отказ от классических программных технологий для десктопного программирования и продвигают новые, которые раньше применялись только в Вебе — HTML и JavaScript. Это пугает всех разработчиков настольных приложений для Windows, потому что они, по сути, теряют весь наработанный опыт и становятся в положение новичков на рынке (речь как об индивидуальных разработчиках, так и об огромных компаниях).

Почему Microsoft так поступает? Пытается тягаться с Google и Facebook? Или просто в компании понимают, что уже в ближайшем будущем суть операционной системы, как и классического десктопного прикладного программного обеспечения, в корень изменится?

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

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

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

С развитием скоростного, постоянно- и повсеместно-доступного Интернета ситуация начала меняться. Стали появляться веб-сервисы, ориентированные на замену старого десктопного софта. Прямая связь между компьютером пользователя и серверами размывалась стандартными протоколами Интернета. Значительно упростились требования к пользовательскому железу. И самое главное, что выбор операционной системы перестал влиять на выбор сервисов, потому что все они работали на технологиях, которые не зависят от платформы: HTML+CSS, XML, JavaScript.

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

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

Коренным образом изменились для разработчиков и критерии выбора операционной системы — отпала необходимость выбирать ту же ОС, что и у пользователей

Да, мы пользуемся большим количеством онлайн-сервисов, но подавляющее большинство софта по-прежнему все еще офлайн! — скажите вы, — Тогда о чем говорить: ничего не поменялось!

Нет, поменялось. Забудем пока о работе и рассмотрим досуг. Что нужно среднестатистическому пользователю домашнего ПК? Простенький текстовый редактор для написания заметок в блог. Простой табличный процессор для ведения домашней бухгалтерии или расчета стоимости покупки телевизора в кредит. Простое приложение для базового редактирования, хранения, каталогизации и просмотра фотографий и видео. Приложение для прослушивания музыки. Болталка (IM) для коммуникаций с другими людьми. И, конечно, браузер для чтения новостей. Пожалуй, все.

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

Сейчас весь перечисленный список программ доступен в Вебе бесплатно! Возможно, для русского человека выделенное курсивом слово безразлично — у него и так все бесплатно. Давайте на секунду представим, что все это надо купить. А еще надо купить операционную систему, чтобы оно работало. Возможно, покупка набора нужного ПО обойдется дороже, чем стоимость ноутбука, на котором оно будет работать. Так что выделенное курсивом слово дает возможность сэкономить раза в два.

Работая с веб-приложениями ничего не нужно устанавливать и обслуживать. «Сломалась» Winsows? Нет проблем, переустановить ее не сложно. Сложно поставить и настроить после установки еще 15 программ. С веб-сервисами это не нужно, для пользования ими достаточно даже встроенного в ОС браузера. А это дает еще один большой дополнительный бонус — мобильность.

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

Фактически, для среднестатистического пользователя больше не требуется от операционной системы ничего, кроме возможности включиться и запустить браузер, чтобы пользоваться облачными веб-приложениями. Тогда зачем ее покупать? Можно взять простую бесплатную ОС. Например, Chrome OS. Именно эту нишу спешно пытается занять Google. Linux — не конкурент для Windows на десктопах, конкурент для Windows — это Chrome OS.

Пока у Microsoft есть фора перед Google. У них есть пользователи. Один раз Google уже обыграл Microsoft на их поле — доля браузера Chrome уже больше, чем Internet Explorer. Скоро Google постарается повторить свой успех в чемпионате разработчиков операционных систем. Что особо забавно — с тем же именем — Chrome. Очевидно, что в Microsoft все это прекрасно понимают и пытаются действовать на опережение. Почитайте заметку Джоэла Спольски «Огонь и движение» — во второй половине он как раз об этом пишет.

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

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

Сегодня такое будущее не представляется реальным в обозримой перспективе — снова парируете вы. Да, нужно признать, что огромное количество программных продуктов пока не готово к переходу в облака (вы можете называть «это» как хотите, но суть не изменится; мне больше нравится слово «облака», чем, например, «режим онлайн»). Но уже сегодня по всем фронтам разработки все идет именно к этому! Игры — класс самых тяжелых для переноса в Сеть приложений. Но, посмотрите — в последнее время появляется все больше серьезных браузерных онлайн-игр (например, Command & Conquer). Их качество растет. Рабочие приложения для бухгалтеров, инженеров, дизайнеров, программистов тоже начали переход— постепенно появляются онлайн-аналоги десктопного софта. 1С, Adobe и другие гиганты ставят «облачные» цели (правда, причины там другие).

Кто-то делает это потому, что модно. Кто-то — потому, что понимает все описанное выше. У других причины свои. Но в любом случае — сейчас все начинают. Полностью перейти в онлайн пока не реально, и это нормально. Вспомните, сколько времени занял переход от консольных приложений к GUI. Во многих банках до сих пор сотрудники работают в DOS, хотя уже больше 20 лет прошло. Переход в облака займет еще больше времени, потому что задача на порядок сложнее. Но рано или поздно веб-технологии достигнут нужного уровня и переход произойдет. Кто будет больше готов к нему лучше, тот и выиграет. Кто не будет готов — останется не у дел. Мы уже проходили такое в истории индустрии программного обеспечения, и будем проходить снова во время каждой очередной смены эпохи технологий.

Так каким же я вижу будущее операционных систем? Операционная система станет чем-то похожим на веб-браузер, установленный на голое железо. Современный классический интерфейс (разработанный в Xerox PARC и впервые внедренный Apple почти 30 лет назад) отойдет в прошлое. Многие современные составные части ОС станут попросту не нужны, другие скроются от пользователя и превратятся в сервисы API для программистов. Основной задачей ОС станет предоставление возможности запуска клиентской части облачных сервисов. И преимущества, которые имеет Microsoft в современном мире ОС, будет значительно растеряны. Им придется придумывать новые способы привязки к себе пользователей и программистов в новой среде, более конкурентной, по сравнению с нынешней.

Когда это произойдет? Думаю, ответить не сможет никто. Многое зависит от решений, успехов и неудач крупных софтверных компаний, таких как Microsoft, Google, Facebook. В отличие от той эволюции софта, которую мы наблюдали в девяностых и двухтысячных, новая эволюция все меньше будет зависеть от производителей железа, и все больше — от производителей конечного ПО для пользователей.

Регистрация на мероприятие начнется 16 мая. Количество мест ограничено.

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

Подробную информацию о мероприятии читайте здесь.

С одной стороны их труд действительно достоин уважения. Они сделали относительно недорогое решение за короткий срок в условиях ограниченных финансовых возможностей. Причем, эту услугу они вывели на мертвый рынок Беларуси. С другой стороны фейлов в Active Cloud получилось немало. Как раз об этих фейлах я и хочу рассказать.

Все описанное ниже касается белорусского Active Cloud. Я не знаю, отличаются ли услуги, предоставляемые в других регионах. Возможно, там что-то по-другому.

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

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

В панели биллинга много непонятной и лишней информации, в том числе, похоже, никому ненужных цифр. Примером может служить вкладка «Статистика и анализ». Это обратная сторона универсальности («коробочное» решение от Parallels). Есть и баги. Например, у меня не работает вкладка «Статистика трафика» — она просто не подгружается.

Кстати, интерфейс для общения с саппортом — отдельная тикетная система с базой знаний. Раньше она была топором врублена в биллинговую панель — было жутко неудобно. Похоже, разработчики это поняли и стали открывать ее в новом окне. Однако, она осталась неудобной. Слоновые заголовки, «потеря» страницы после F5 (это следствие отсутствия правильного URL в address bar), опять лишняя информация, причем частично на русском, частично на английском. Засоряют экран специальные уведомительные тикеты, которые плодятся вместе со счетами и виртуальными машинами. Здесь достаточно было бы уведомлений по e-mail.

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

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

При создании виртуальной машины ей задается группа (вписывается в текстовое поле). Все группы видны в меню. Машину можно удалить, но при этом группа не удалится. И переименовать группу нельзя. Раздражает.

Консоль виртуальной машины вроде работает без Java. Но она сделана на картинках-слайсах. Т.е. при изменении изображения на виртуальном экране виртуальной машины (консоль или GUI) подгружается новые картинки-квадратики. Из-за этого консоль работает медленно и с большой задержкой. Пользоваться ей неудобно.

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

Кроме того, в панелях были конкретные баги. Пару раз писал в саппорт, обещали поправить. Поправили или нет — не проверял.

Само облако поначалу сбоило. Лично мне несколько раз саппорт решал проблемы отвалившейся на моей ВМ сети. При мне сеть во всем облаке (толи целиком, толи в его куске) полностью падала на несколько часов. После этого столкнулся с тем, что свежеустановленная из образа Debian x64 не получала IP по DHCP на первом и всех последующих запусках (повторялось каждый раз). После обращения в саппорт проблема была решена за пару дней. Я был в шоке…

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

Изначально мы хотели перевести в облако свои серверы. Но сделать это не смогли. Основной причиной тому были непонятные проблемы с производительностью дисковой подсистемы. Хотя синтетические измерения вроде бы и выдавали нормальные скорости I/O, но фактическая производительность рабочего сервера на Windows у нас оказалась колоссально хуже, чем на аналогичном по конфигурации голом железе.

Возможно, проблемы были на большом количестве IOPS (частое чтение мелких блоков). Мы не выяснили это до конца. Но факт есть факт: то, что у нас нормально работает на физическом выделенном сервере, перенести в облако мы не смогли — сильно педалит. Причем, четко видно, что педалит не по CPU, и не по памяти. Педалит именно по дисковому I/O.

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

Мне нравится Active.by. Я желаю им успехов в развитии. И надеюсь, что мой пост поможет им раскрыть глаза на собственные недостатки и исправить их. Удачи им в этом!

Актуальность информации — апрель 2012 года.

1. Мы хотим контролировать скачивание больших файлов, проверяя права доступа или считая количество закачек. Мы используем nginx и PHP (или другой серверный язык).

Это реализуется очень просто через заголовок Accel-Redirect. nginx получает запрос, передает его скрипту, скрипт в заголовки ответа выдает Accel-Redirect с ссылкой на файл, который нужно выдать пользователю. Если файл выдавать нельзя (например, нет прав), скрипт просто выдаст ошибку (например, 403).

В данном случае не важно, работает ваш PHP через проксирование из nginx на Apache, либо на *CGI. Предположим, что вы хотите отдавать на скачку файлы, которые находятся в каталоге /var/files. Тогда в секции server в nginx добавьте:

location /_download_files {
        root /var/files;
        internal;
}

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

header("X-Accel-Redirect: /_download_files/filename.zip");

Никакой выдачи (echo) делать не надо, после отдачи заголовка можно завершить работу скрипта. В этом случае будет скачан файл /var/files/filename.zip. Вместо filename.zip может быть любой длинный путь с каталогами, который должен повторять путь к файлу в /var/files/.

В принципе этого достаточно, чтобы переложить выдачу файла на плечи nginx. Если нужно обязательно показать диалог закачки (даже если файл такого типа, который браузер может показать сам), нужно добавить выдачу заголовка:

header("Content-Type: application/x-force-download");

Обратите так же внимание на то, что в случае проксирования на Apache последний обязательно установит Content-Type (по умолчанию обычно text/html) в случае PHP-скриптов, и этот тип отправится пользователю, так как nginx его не перепишет при выполнении Accel-Redirect. Т.е. в этом случае эту строку нужно писать обязательно. Как будет в случаях с *CGI, не знаю — не проверял.

Чтобы предложить пользователю имя файла для сохранения, отличное от того, что в адресной строке (это особо актуально в случаях «download.php&file_id=12332»), отправим такой заголовок:

Content-Disposition: attachment; filename="Super File Name.zip";

2. В такой схеме при проксировании на Apache не работает докачка. Исправляем.

Докачка в HTTP работает через HTTP-заголовок Range. В нем указывается с какого байта начать передачу. Можно так же указать, сколько байт нужно передать. Это передается в запросе. Например:

Range: bytes=33-
Range: bytes=33-100

Первый вариант просит отдать весь файл, начиная с 33 байта (включительно). Второй вариант просит отдать с 33 байта по 100. Чтобы браузер понял, что докачка поддерживается, сервер отдает в ответе заголовок:

Accept-Ranges: bytes

Докачка не работает из-за того, что HTTP-заголовок Range попадает в Apache после просирования и последний думает, что его просят отдать кусок PHP-файла. А он это делать не хочет и отдает ошибку: HTTP/1.1 416 Requested Range Not Satisfiable.

Исправляется это довольно легко — просто зануляйте при проксировании Range (это нужно добавить туда, где у вас описано проксирование на Apache в конфиге nginx):

proxy_set_header   Range   "";

Тогда Apache (или PHP-скрипт) ничего знать про него не будут и спокойно сделают свое дело. А nginx после Accel-Redirect отдаст ответ в соответствии с запрошенным Range.

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

3. Даже так не работает докачка в IE 9.

Да. На сколько я понял методом простого тыка, IE требует поддержки ETag сервером для работы докачки. Игорь Сысоев (разработчик nginx) отказался внедрять в nginx поддержку ETag. Поэтому из коробки работать докачка в IE 9 не будет точно. Если это жизненно необходимо, пробуйте смотреть сюда (Ctrl+F Etag).

4. А как работает докачка в других браузерах?

Везде есть свои особенности. В общих чертах случай докачки выглядит так. Запрос/ответ на скачку (начало скачки):

GET /file.zip HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
Server: nginx/1.0.3
Date: Tue, 06 Mar 2012 18:09:47 GMT
Content-Type: application/x-force-download
Content-Length: 13686314
Last-Modified: Thu, 23 Feb 2012 13:50:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="Supre File Name.zip";
Accept-Ranges: bytes

Запрос/ответ на докачку:

GET /file.zip HTTP/1.1
Host: example.com
Range: bytes=5393683-

HTTP/1.1 206 Partial Content
Server: nginx/1.0.3
Date: Tue, 06 Mar 2012 18:10:11 GMT
Content-Type: application/x-force-download
Content-Length: 8292631
Last-Modified: Thu, 23 Feb 2012 13:50:26 GMT
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Disposition: attachment; filename="Super File Name.zip";
Content-Range: bytes 5393683-13686313/13686314

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

Opera. Она шлет указание на то, что «если файл не менялся со времени Last-Modified в первом ответе, дай мне указанный кусок; иначе — отдай мне весь файл заново». Делается это с помощью заголовка If-Range в запросе:

GET /file.zip HTTP/1.1
User-Agent: Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.10.229 Version/11.61
Host: example.com
Accept text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, ..., */*;q=0.1
Accept-Language: ru-RU,ru;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
If-Range: Thu, 23 Feb 2012 13:50:26 GMT
Range: bytes=5393683-

Firefox. Он делает немного иначе. Используется заголовок If-Unmodified-Since с указанием того же времени из Last-Modified. В этом случае сервер либо вернет запрошенный кусок (если файл не менялся), либо отдаст ошибку 412 Precondition Failed. Выглядит это так:

GET /file.zip HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-ru,ru;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Range: bytes=5878651-
If-Unmodified-Since: Thu, 23 Feb 2012 13:50:26 GMT

Chrome. Этот «пильмень» — самый хитрый. Он вообще не поддерживает докачку, хотя делает вид, что поддерживает. При постановке закачка на паузу он просто шлет некие TCP-пакеты для поддержания соединения. Когда сервер понимает, что его дурят, он разрывает соединение. Если дождаться этого момента и нажать в Хроме «Продолжить», он сделает умный вид, будто файл полностью скачался и все ОК, но при этом он останется в том размере, в котором успел скачаться до паузы.

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

IE. Про версию 9 уже сказано выше. Она требует работы Etag для поддержки докачки. В данном контексте ETag — это просто контрольная сумма файла. Когда Etag файла передается в первом ответе от сервера, IE даст возможность прервать скачку. При попытке докачки он отдаст заголовки:

GET /file.zip HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Host: falcongaze.com
Range: bytes=3494051-
Unless-Modified-Since: Mon, 05 Mar 2012 08:31:06 GMT
If-Range: "1448453-f77f31-4ba7abf5a8680"
Connection: Keep-Alive

В добавок к If-Range он передает нестадартный заголовок Unless-Modified-Since — вероятено IIS его обрабатывает (только не понятно, зачем он, если есть стандартный If-Unmodified-Since; может для поддержки старых версий IIS?).

Собственно в первом ответе Etag выглядит примерно так (если он поддерживается сервером, например, Apache):

...
ETag: "1448453-f77f31-4ba7abf5a8680"

Дополнительная информация:

• RFC 2616. Header Field Definitions;
• List of HTTP header fields.

Ценность материала в том, что:

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

2) конкретные советы о том, что следует почитать/посмотреть.

Ссылка на материал: Как стать хорошим программистом и хорошим php-программистом в частности?

А ниже позволю себе сделать частичный копипаст предложенных решений.

Мастерство программирования (или скорее можно назвать Основы)

• Совершенный код,
• Чистый код,
• Рефакторинг,
• Программист-прагматик,
• Архитектура корпоративных программных приложений,
• Кодеры за работой.

Нашел очень хорошую и исчерпывающую статью на английском: How to be a Programmer: A Short, Comprehensive, and Personal Summary

Курсы, выложенные по MIT OCW:

• MIT Electrical Engineering and Computer Science

Курсы Стэнфорда:

• Mashine learning
• Natural Language Processing class
• Software Engineering for Software as a Service class

На каждом сайте внизу есть ссылки на другие курсы Стэнфорда.

Алгоритмы.

Как развивать:

Искусство программирования Кнутта — читать и выполнять задания.

Project Euer — задания по алгоритмам, можно писать на PHP.

ООП и Шаблоны проектирования

PHP: объекты, шаблоны и методики программирования М. Зандстра сейчас, наверное, лучшая книга для введения в шаблоны проектирвания для PHP.

Head First Design Patterns, на русском Паттерны проектирования — очень рекоммендуют, как очень хорошо разъясняющую книгу.

какие книги, методы обучения, задачи порекоммендуете?

PHP основы

Как развивать:

собственно работа по профессии и набор опыта,

Профессиональное PHP программирование — вроде как лучшая книга по основам PHP (читать, чтобы заполнить пробелы по основам языка, начиная с типов и далее. Посмотреть, что есть из того, чего я не казался в работе, чтобы расширять кругозор.

Потом есть stackoverflow, там введи в поиск ~php~ и читай вопрос, давай свой ответ (про себя), потом смотри, что другие написали. Будешь по тегам смотреть заодно, что пхп-ники изучают.

Javascript Основы

Как развивать:

собственно работа по профессии и набор опыта,

JavaScript. Подробное руководство. Д. Флэнаган (читать и разбираться в пропущенных основах — типы, обьектная модель и др.)

JavaScript: The Good Parts

JavaScript. Шаблоны

Источник: Как стать хорошим программистом и хорошим php-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

Все предложения хостинга можно разделить на 4 группы: Shared hosting (общий сервер), VPS (virtual private server — частный виртуальный сервер), Dedicated (выделенный сервер) и Cloud (облачный хостинг). Colocation (размещение сервера) в расчет не берется, так как это просто аренда места в стойке, а не хостинг.

Итак, с чем же можно провести аналогию?

Первое, что пришло в голову — ресторан. Shared — небольшой стол, заполненный едой, а вокруг стоя тянет руки толпа студентов. VPS — типичный ресторанный стол, у каждого своя еда на тарелке, присутствует малая группа людей. Dedicated — один за столом. Cloud — вот тут самое интересное. Толком придумать идею не получилось. Если у кого получится, велкам в комменты.

Чтобы восстановить пробел с Cloud, решил перенести фокус со стола на одну емкость — стакан. Shared — стакан с жидкостью забит трубочками. VPS — стакан перегородками поделен на 4 равные части, в каждой части своя трубочка. Dedicated — одна трубочка в стакане. Cloud — система стаканов, соединенных трубочками. К этой системе равномерно подключаются трубочки «клиентов».

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

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