А вот гнездо главных сквик блоггеров -- http://planet.squeak.org/ (гнездо главных крокет-блоггеров http://planetcroquet.squeak.org/).
Проглядываешь это всё, и разговоры про Web 2.0 кажутся какими-то уж очень древними. Вот, например, пост про OpenID и аватар -- http://www.meshverse.com/2007/04/06/open-avatar/ (это к тому, что аватары Second Life и Ogoglio могут быть разделяемы с аватарами в Croquet).
А еще вчера я провел пару часов в разговорах о Web 3.0 приложениях, которые выходят в публичный доступ этой осенью. Вот это, понимаю, новизна. А Web 2.0 -- что об этом говорить, зачем его делать? Это уже коммодити, этим нужно просто пользоваться...
Или вот работа Николая Суслова: http://nsuslovi.blogspot.com/2007/04/croquet-sdk-10-and-tweakui-on-sophies.html "Крестьянство" = XUL от Sophie для описания Tweak Croquet. Можно дизайнить крокетовский твик-интерфейс, используя просто XML и CSS. Я не понимаю, насколько это в стиле самого Крокета, но мультимедиа-диски (как заявляет сам Николай) это точно помогает авторить.
Для того, чтобы оказаться женой генерала, нужно вовремя выйти замуж за лейтенанта. Я не знаю, сам ли Крокет станет мейнстримом ближайшего будущего, но что он повлияет на состояние многих и многих умов заложенными в нем концепциями -- это факт.
Пока понятно одно:
а) чтобы выглядеть солидным, нужно программировать на чем-нибудь модном и устоявшемся. При этом молчаливо предполагается, что программирование будет быстрым, ибо программы будут "собираться" из уже кем-то когда-то написанных блоков. Для модных систем таких блоков обычно навалом, есть мощный инструментарий разработки. Инвесторы спокойны, хотя производительность и мала.
б) мощная система разработки и открытость кода снизу доверху позволяет маленьким коллективам делать большую работу -- при этом большие системы собираются из маленьких кирпичиков "снизу вверх" (и это занимает меньше времени и сил, чем можно было бы ожидать при подходе "снизу вверх"). Язык разработки берется не модный, а мощный, и его лучше не называть публично в силу немодности и непонятности (все непонятное пугает инвесторов и покупателей), а торговать только конечную систему ("мы продаем вам не сверло, мы продаем дырки!"). Тут трудно с opensource: кодов стесняются именно в силу выбора языка/системы программирования. Беда такого подхода -- относительно мало разработчиков, крутая кривая обучения новеньких, трудность "продажи инвесторам" и "продажи покупателям". Поэтому такой подход берется больше для исследовательских, нежели "промышленных" проектов. Сквик именно из этой категории.
в) берется супермощный и абсолютно новый язык (eiffel, self, или даже combined object-lambda из проекта FONC). Все очень круто и быстро, только инструментария еще маловато, разработчиков вообще не найти. Если свезло, то ситуация быстро улучшается: число разработчиков растет, часть разработчиков улучшает инструментарий. Если не свезло, то через некоторое время не столько пишешь свою систему, сколько развиваешь языковую среду и учишь людей вокруг себя.
Предположим, что я хочу сделать коллаборативную офисную систему (скажем, финансовый учет для небольшого холдинга из пары десятков предприятий, чтобы вы не думали про "коллаборативное редактирование в OpenOffice" ;) . Тогда:
а) выбор традиционной системы программирования (обычно сегодня это Java) -- это старт традиционной разработки. Инвесторы спокойны, время разработки долгое, система будет весьма похожа на традиционную по тому, как с ней работать (уж так всенепременно получится). Отличаться будут только алгоритмы, модель данных и т.д.
б) выбор "нетрадиционного языка" приведет к тому, что разработчики смогут позволить себе разные эксперименты. Разработка будет во много раз быстрее, система наверняка будет "контринтуитивной" для первого использования продвинутыми пользователями сегодняшних виндов, и много удобней для новеньких (ибо каждое новое поколение интерфейсов обычно снижает порог вхождения). Для тех людей, которым важен язык разработки, это будет неприемлемое решение, вечный источник критики, религиозный вопрос.
в) выбор абсолютно новой системы приведет к тому, что первые полгода никаких результатов не будет ("разрабатывается инструментарий" и "обнаружили и победили очередную багу в системе"), а затем все резльтаты будут получены буквально за месяц-два. Мощность языка и недостаток инструментария приведут к тому, что скорость работы (по моей оценке) будет примерно равны скорости работы по варианту "б".
Я бы сейчас брал Крокет, и пытался бы сделать систему в нём: импортируя необходимые пакеты функциональности и инструменты из Сквика. Тогда есть шанс, что через три года получится абсолютно современная коллаборативная система (три года -- это нормальный срок взросления большого программного проекта). Подводных камней там множество, но это интересные камни:
а) система p2p -- и нужно еще подумать, как это соответствует структуре современных холдингов, в которых все время что-то продается, а что-то покупается и нужно понимать, как там внедряется новый софт.
б) коллаборативность (и тем более -- коллаборативность в 3D) для приложений в области финансов мало кем рассматривалась, если не считать разных решений для "ситуационных комнат".
в) непонятно, как привинтить сюда оргмоделирование (описывать, например, ту самую формальную структуру холдинга, или структуру сквозных бизнес-процессов).
г) нужно исследовать все эти вопросы транзакционности (хотя с этим в последнее время идет война: все транзакции объявляются "длинными" и далее все программируется в этой части вручную), бэкапности/версионирования, надежности, многопользовательскости.
д) наверняка будут и еще неожиданные препятствия, которые сообщество системы программирования решит через три года, но решения которых потребуются буквально в первый месяц.
д) нужны люди, у которых "мозги не испорчены бейсиком" (которые имеют вкус к Программированию, а не тупому скриптингу приложений).
Какие приложения я бы делал? Такие, которые вряд ли сделает кто другой другой:
а) голдратовская система управления проектами/процессами в холдингах, построенная на базе чего-то такого, как Gjallar ("JIRA на стероидах"). Унифицированное представление проектов, процессов, программ, поручений, процедур и т.д.. "Процессы by example" и прочие идеи в этой области.
б) финансовый учет "глобального максимума" для холдингов -- с различением консолидированной управленческой части и проекцией на бухгалтерскую часть с разделением по юридическим лицам ("финансовая схема").
То есть я бы делал что-то типа http://www.inherentsimplicity.com/ или http://realization.com/ -- только
а) opensource
б) коллаборативный интерфейс
в) распределенная архитектура
г) в варианте учебной системы (достаточно мощной для промышленного применения -- но с которой можно изучать предметную область ;)
д) русскоязычный интерфейс