Если коротко — я в восторге. Точно даже не знаю почему, но предполагаю, что по двум основным причинам:

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

Ну правда ведь, если вы не используете какую-либо специализированную программу для каких-нибудь чертежей, то подавляющее большинство времени (за компьютером) вы работаете только с интернет-браузером. С чем мы там ещё работаете? Ах да, с почтовой программой и «офисом». Так и это можно делать в браузере. Gmail по мнению многих уже значительно удобнее многих десктопных почтовых клиентов. У программ из серии «microsoft office» уже давно есть веб-аналоги, вроде google docs и других даже более навороченных. Пусть они (пока) и не такие крутые по функционалу, но большинство пользователей о существовании продвинутого функционала десктопных «офисов» даже не слышало.

Любой более-менее IT-шник легко распознает в новой поделке Гугла повторное изобретение велосипеда тонкого клиента. Принцип (или технологию — не знаю, называйте, как хотите) тонкого клиента придумали много лет назад и даже много где применяют. Но тут, на мой взгляд, тонкий клиент подан под очень правильным соусом и у него есть шанс обрести популярность. Очень быстрая загрузка, очень продуманная безопасность, расширенные возможности для веб-приложений — всё это, я надеюсь, поспособствует распространению концепции в массы.

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

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

Джеф Сазерленд (Jeff Sutherland) поделился статистикой в пользу маленьких команд, согласно которой стоимость условной единицы (function point) работы команды из 7-ми человек составила $566, а из 14-ти — $2970. Аналогично, в ответ на пост на InfoQ об увеличении команды и производительности Мишкин Бертейг ( Mishkin Berteig) прокомментировал:

Представьте, что вам «дали» команду разработчиков из 100 человек. Теперь представьте, что вам поручили очень важный проект. Что будет лучше:

а) Задействовать в проекте всех 100 разработчиков (с хорошим проджект-менеджментом, руководством и т.п.), или...

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

Лично я, невзирая на суровость сценария б), определённо поставил бы на него, а не на сценарий а).

Юрген Аппело (Jurgen Appelo) предположил, что оптимальный размер команды, вероятно, всего 5. Пять — это общее число, основанное на различных исследованиях о взаимоотношениях и структурах команд.

• Скрам рекомендует размер команды 7±2 человека. Таким образом получается вариация между 5 и 9.
• Согласно «Cognitive Edge», человеческий мозг эволюционировал вместе с окружающими социальными условиями, и существует естественное ограничение на количество поддерживаемых социальных связей. Коротко учение можно выразить правилом 5, 15 и 150. 5 - естественное ограничение кратковременной памяти, 15 — естественный уровень глубокого доверия, а 150 — количество личностей, которое человек может держать в голове.
• Другое исследование, основанное на законе Паркинсона, предполагает, что команда с любым количеством участников меньше 20, кроме 8, вполне работоспособна. При количестве больше 20 начинается естественное деление на подгруппы, и согласованность не может быть достугнута. При восьми — часто происходит патовая ситуация во время принятия решений.

Ещё один аргумент в поддержку 5-ти — комментарий PMHut к вышеуказанной статье (про связь с законом Паркинсона):

Чем больше членов в команде, тем больше коммуникационных каналов возникает между ними, их количество растёт экспоненциально. Для 3-х членов мы имеем 4 коммуникационных канала, для 4-х — 9. Думаю, формула такая: m-1 ^ 2.

По-моему, идеальный вариант — маленькая команда из 4 или 5 членов.

Примечание переводчика: с точки зрения математики выкладки неверны (там дальше их опровергают 2 раза), но суть от этого не меняется.

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

Однако, несмотря на сильные доказательства в пользу команды из 5-ти, Юрген предупредил, что прежде, чем слепо следовать рекомендациям по размеру, командам следует попробовать самоорганизоваться и постепенно подобрать оптимальный размер. Цитирую:

Когда вам нужно организовать большой проект, не навязывайте людям «предпочтительный» размер команды только потому, что так написано в книжке. Попробуйте позволить самоорганизации сделать свою работу и дайте людям самим (внутри своего реального окружения) вычислить свой оптимум. Они хотят разделить свою команду из семи на две по 4 и 3? Конечно, почему нет? Они объединяют две команды в одну большую из 15-ти? Прекрасно, позвольте им проверить, сработает ли это.

От себя могу добавить, что моя команда показывала максимальную производительность (на душу), когда состояла из четверых (к сожалению, не получилось наблюдать команду пятерых). Как мне кажется, это связано не только с упрощением взаимодействия в команде, но и с качеством (если так можно выразиться) и совместимостью личного состава — команда команде рознь. Однако, в общем и целом я согласен с тем, что где-то около 5 ± чуть-чуть членов в команде — самое то. Больше 7-ми — это уже многовато.

Так вот, сегодня промелькнула идея, что можно вести аж целый полноценный блог, посвящённый косякам Internet Explorer'а, да и остальных представителей рода браузерного, ведь в их полку теперь прибавилось: Safari под масдай наберёт популярность, как мне кажется.

Например, недавно, написал правильный фича-реквест в проект Eclipse PDT, только что-то никто на него мне пока ничего не сказал и не проголосовал. Так что активно подключаемся и голосуем, кому это нужно.

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

Так что я не совсем дармоед , и иногда даже как-то пытаюсь помочь ребятам-энтузиастам.

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

НО... Как говорит Денис: «Корень всех бед — преждевременная оптимизация».