Платформа Абрикос5 лет работы, версия 0.5.5, пора рассказать сообществу что это за зверь

Как быстро все-таки летит время!
2008 год, опубликован первый релиз на гуглекоде. Позади год неоднократной переписки ядра в поисках решения, которое определит вектор развития всего проекта. Цели уже определены, но сомнения, что они не приведут в тупик, не покидают меня. И страшное в этих целях не их масштаб, а то, что они по своей сути пойдут в некотором роде против общего течения.
«Элементы интерфейса вперемешку с кодом, да и еще и запросы к БД и тут же полученные данные опять вперемешку с кусками кода, а потом вся эта каша разбавляется неизвестно чем и на выходе сервер отдает страницу, так необходимую пользователю. А сервер ведь один, а пользователей так много… И это каждый раз, всякому пользователю… Благо успели изобрести хоть какое-то кеширование…» — такие мысли атаковали мне голову, всякий раз, когда я просматривал очередной код какого-нибудь скрипта/движка сайта.
С этим нужно что-то делать…

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

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

Какая все-таки несправедливость в этих веб-технологиях… Как то надо начинать исправлять ситуацию… Пусть не в глобальном масштабе, но хоть в каком то проценте.

Сервер должен отдавать сырцы, а клиент из них строить интерфейс сайта, в процессе подгружая необходимый контент. Тогда сайт будет приложением, а по сети после всей инициализации в основном будет ходить «чистый» контент. Причем сырцы обязательно должны быть сжаты, а у браузера закешированы. Чтобы при повторном открытии страниц, практически весь интерфейс был взят из кеша. О каких либо технологиях по типу флеша, серверлайт и т.п. речи быть не может. Нет, я не против них, для определенных случаев они возможно незаменимы, но есть JavaScript. Замечательный язык! Язык, на котором можно спроектировать самый изощрённый алгоритм с наименьшими потерями. Одна только технология передачи функции в параметрах чего стоит.

А стандарты. Что с ними?
Со стандартами тоже станет все значительно проще. Так как сервер будет отдавать контент в JSON в чистом виде, то любое приложение с легкостью уже сможет обработать этот контент в своих приложениях.
И когда в сети интернет контент будет навсегда отделен от интерфейса и элементов управления, с этой технологией можно будет вступить на новый уровень развития интернет.

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

Фантастика? Ничего подобного! Интуиция раз сказала что возможно, значит нужно начинать проектировать такую систему.
 
Задумал и сделал
2008 год, все разложил по полочкам и опробовал на практике, подняв несколько различных сайтов. Хотя страницы сайта по — прежнему отдают клиенту контент со шлаком, зато вот админка! 2кб объема пересылок при повторном заходе в нее. По каналам связи ходят в основном контент данные. Весь интерфейс и его элементы управления уже с первого захода в браузер находятся в кеше. А для других разделов админки, которые не открывались в прошлый раз, сервер подгрузил все необходимые компоненты и сложил их в кеш. Да и еще компоненты разбиты на библиотеки, большая часть повторяющихся функций, вынесены в отдельные компоненты (классы, функции), которые подгружаются только по мере необходимости.

Теперь, каждый раз заходя в админку очередного своего сайта с телефона и трафиком в 5 руб. за мегабайт, я спокоен. И даже не потому, что на управление сайтом уходят копейки, а потому, что сам факт того, что это работает и вполне исправно, открывает такие просторы.
 
WebOS
И вот на горизонте я вижу следующую идею — а не построить ли мне операционную систему работающую в браузере? Да, да, я знаю, уже есть такие. Но идея то не в том, чтобы сделать эту WebOS под ключ, а в том, чтобы платформа смогла с этим справиться. Ведь WebOS это и есть смысл поставленной цели на данный момент перед платформой.

И тут, конечно же, начинаются очередные сложности. Например, есть интерфейс (шаблон) панели на стороне клиента. Он прекрасно работает в админке, но в WebOS нужно открыть этот же самый интерфейс во множестве экземпляров. А идентификаторы HTML элементов шаблона заданы в статичном виде. И обратиться из Dom к этим идентификаторам уже нельзя. Значит нужно найти решение, при котором идентификаторы будут по-прежнему понятны для разработчика, но для платформы они станут динамические. И уже на каждый экземпляр элемента интерфейса движок будет создавать свои уникальные идентификаторы, с которыми будет так же легко работать как со статичными. И, конечно же, решения были найдены не только на эту сложность, но и на все возникающие. Потому что тот самый вектор, который был выбран на стадии проектирования целей проекта, был выбран правильно, и до сих пор играет в этих решениях значительную роль.

И вот еще один год плотной работы над платформой.

Рабочий прототип WebOS готов. Вся WebOS при первом запуске для браузера весит всего примерно 150кб. Все остальное подгружается динамически по мере вызова и, конечно же, складывается в кеш. Повторный заход в WebOS и работа в приложениях обходятся клиенту в килобайты и это так приятно, против двух/трех метров аналогичных систем.

Тут же стартует такие приложения как «Календарь для сотрудников компании», закрытое приложение «Управление продукции на предприятии» и другие, которые работают в WebOS. Я активно внедряю их в разные организации и наблюдаю, как все это работает на различных браузерах, серверах. Да простят меня пользователи, но цель всех этих приложений тогда было отладить, отточить и просмотреть технологию WebOS в действии.

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

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

Например.
В 2011 году мы входим в состав организаторов фестиваля «Всероссийский Велофестиваль Казань-Велосфера 2011». Наша роль создать официальный сайт фестиваля. Интересует меня в этом проекте не сам сайт и то что на нем будет в какой то степени пропиарена платформа, а то, что можно будет применить на практике работу системы WebOS и приложение «Доска проектов» в другом ключе.

В итоге система очередной раз оправдывает себя. Большая часть внутренней работы по организации фестиваля идет в этой системе. Участники добавляют идеи, ставят задачи и все вместе обсуждают их. Кто-то создает приватные беседы и обсуждает их тет-а-тет.
Все участники разбросаны по Казани в разных ее частях из разных компаний, состав участников разный, кто-то с компьютером на «ты», а кто-то вообще с ним не дружит, но и те и другие вполне успешно справляются с системой.
И все это происходит в одном месте. Вот он сайт, вот она система.
Короче говоря, WebOS отлажена, приложения тоже работают исправно, компании довольны. Но не доволен я. 
 
BosUI
Я наблюдаю вживую за поведением пользователей (секретарш, бухгалтеров, прочих рядовых пользователей и не только) как они по началу начинают путаться, применяя свои навыки работы привычного рабочего стола на рабочий стол WebOS.

Рабочий стол WebOS в браузере, а браузер на рабочем столе операционной системы компьютера пользователя. Не многовато ли рабочих столов на одного пользователя?

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

Я копирую модуль WebOS в Bos и меняю интерфейс.
Начинаю экспериментировать над системой приложений и выпускаю «Менеджер задач Botask».

Вот это уже практически то, что нужно. Да, немного неудобно, интерфейс хромает, но эта система начинает работать в нашей команде. Все проекты, идеи, общение и просто переписка с этого момента идет только через эту систему.
Ох, как я и моя команда рада! Наконец-то весь материал, разбросанный, где только можно, мигрирует в эту систему. Теперь все в одном месте. Хоть какой то порядок.
 
Рефакторинг исходного кода
Платформа за столько лет плотной работы практически готова к тому, чтобы официально заявить о ней. Но внутренности до сих пор тех времен. Хочется начать писать документацию, но название классов сбивают с толку. Есть участки кода, которые просто выводят из себя. Это раздражает и мешает чувствовать платформу изнутри.
 
Менять, все менять
Четыре месяца и практически полный рефакторинг исходного кода. Так же переписан интерфейс «Менеджера задач — Botask».

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

Еще пару недель и тогда можно будет заявить о платформе.

Приступаю к разработке модуля «Финансы — домашняя бухгалтерия» и через две недели выпускаю базовую версию. Эта версия умеет создавать различные бухгалтерии, управлять счетами и вести операции по ним в разных валютах, выводить простой отчет.

Теперь вроде бы как все, по крайней мере для текущей версии 0.5.5

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

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

Да и спешка эта вызвана тем, что сейчас, благодаря постоянным исследованиям в платформе Абрикос, были открыты новые технологии в сфере построения сайтов и интернет приложений, а так же в сфере передачи и позиционирование контента. На данный момент идет их окончательная разработка и тестирование.
Если не всплывут подводные камни, то уже в ближайшем будущем я представлю сообществу эти изобретения.
 
Да, чуть не забыл
Платформа Абрикос и большинство модулей к ней развивается под свободной лицензией GPL v2.0. В будущем возможно изменение лицензии в сторону послабления, дабы дать возможность разработчикам создавать на платформе свои проекты и зарабатывать на них.
Сайт платформы Абрикос — http://abricos.org
 
В заключении
Конечно, я затянул с началом публикаций информации о платформе Абрикос. Но делал я это сознательно, так как всегда убеждался в том, что публикация отвлекает.

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

Благодарю за внимание.
  • +8
  • roosit
  • 08 февраля 2012, 12:10

Комментарии (2)

Плохо что на пыхе, а не на python-е.
Мне python тоже больше симпотизирует, но PHP был выбран как наиболее «массовый»
Да и потом больше упор делается на клиентскую часть, сервер выступает только в роли компилятор JS компонентов интернет-приложений, поэтому возможно в будущем будет и python версия
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.