The term T-shaped skills is also broadly used in agile software development to emphasize the need for cross-skilled developers and testers in agile teams.

It was a handy concept to point to the difference between T-shaped and I-shaped people – professionals who have deep narrow knowledge in one discipline while lack a good foundation in other related disciplines needed to interact with colleagues, be innovative, think wider, and see the big picture. Lack of broad knowledge limits these people to grow beyond their primary domain and become super-start professionals.

The T-shaped idea is about developing deep expertise in one’s primary area and getting basic skills in the other related areas.” What I do not like in that statement is the “getting basic skills” part. T-shaped approach still limits individuals to become highly valued, productive, and innovative professionals. This resolves the communication and collaboration ussie – basic skills are enough to support effective teamwork. That’s it. In reality, it doesn’t help to handle more complex tasks, be innovative, think wider, and see the big picture.

What does help is to learn deeper more areas than just the primary one? The closer discipline to the primary one, the better it should be learned. This idea leads to the new shape that I called Bell-Shape. The name goes from Bell Curve or normal distribution.

After applying the bell curve to the skills broadness chart we get a new skills depth distribution like this:

In the world of bell-shaped people it’s important to learn deep enough the core discipline, let’s say, programming, learn good enough the most close and critical conjugate disciplines like QA, DevOps, Systems Administration, BI, UX, System, and Business Analysis, etc. Learn the other related areas like microelectronics, math, physics, etc. on some solid level. And finally, gradually learn everything else on a non-zero level to support your personal and professional growth and build a wide horizon.

This idea can be applied to education, recruiting, professional assessments, and even personal life. This bell-shaped approach to learning helps to build a career. Growing up, at some point it’s not enough to understand just your specialty, but important to understand other related ones.

At the same time, the story is not about knowing everything equally deep. Even if it were possible, it doesn’t give any advantage because instead of collaboration and delegation the person would do everything on his/her own. That doesn’t make sense. Growth is about uniting people and motivating them to achieve bigger goals together. The leader needs to be able to talk in different languages with different professionals, but not to do their work on his own.

Building a bell-shaped skill set is a live-term gradual process. In the modern world, it’s not enough to get experience in a specific profession once and benefit from it the whole life. The world is growing so fast that it’s important to keep learning. So, the concept of bell-shaped skills helps determine what level of knowledge in what disciplines is nice to have.

For a Russian-speaking audience, my Youtube video is available on the same topic.

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

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

Хотя бы один из перечисленных факторов озвучивается на каждом интервью. Это список из собеседований программистов, но и для других IT-специалистов (QA, SysOps, DevOps, BA, PM, UI/UX) факторы примерно те же, разбавленные спецификой специальности.

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

Анализируя свои потребности и ценности, я составил аналогичный список для себя.

1. Manager Role / Управленческая позиция

Уже более 5 лет назад я полностью перешел из программирования в менеджмент. Проектный, продуктовый, people-management – всего это было уже много. Суть управления заключается в том, что организуя работу группы людей, можно достигать результатов, в разы превосходящие результаты личные, если например самому заниматься разработкой. Это scaling.

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

2. Engineering / Разработка ПО

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

3. Team / Команда

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

4. Product / Близость к продукт

Это интересный пункт. Раньше я думал, что хочу работать именно в продуктовой компании (и если запустить свое, то только продукт). Сейчас я смотрю шире. “Продуктом” может быть что угодно, что несет добавочную ценность: услуги и решения, построенная команда, созданное предприятие. Свой продукт можно найти почти в любой работе. Вопрос только в том, насколько есть возможность реально вовлекаться и влиять на свой продукт. Вот как раз это и важно при выборе места работы.

5. Salary / Зарплата

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

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

6. Independence and Responsibility / Самостоятельность и ответственность

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

Позитивными сигналами в этом вопросе являются четко поставленные цели (в идеале OKR), внятное описание обязанностей хотя бы в вакансии, понятный объект работы (продукт, клиент, юнит и т.д.).

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

Слайды.

Слайды.

Презентация.

Слайды

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

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

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

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

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

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

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

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

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

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

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

Между дисциплинами существуют 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 мая. Количество мест ограничено.

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

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