Всем привет. Даже не знаю с чего начать писать обзор проекта, над которым трудились несколько программистов приблизительно 10 лет. Писать код намного проще, чем чесать языком, ведь кодом можно выразить любую мысль, особенно когда речь идет о том, чего еще ни разу никто не делал и не у кого подсмотреть текст. Но так или иначе, писать обзор о проделанной работе надо, поэтому не судите строго за возможную тавтологию или некорректные формулировки.
Пожалуй, будет правильнее всего начать с самого начала, как это обсуждалось в далеком 2007-2008 году и почему было решено делать. Однажды, два веб разработчика, живущих посреди России, писавшие сеть сайтов одной Московской фирме и ненавидевшие javascript, потому что тогда его в браузерах выключали, вдруг услышали новость о появлении функции XMLHttpRequest. Разобрались, опробовали, функция выглядела очень вкусно. На Московских заказчиков мы работали на постоянной основе и решили начинить их сайты динамикой. А так как сеть всё разрасталась и разрасталась и конца этому не было видно, мы решили разработать собственную систему управления сетями сайтов. Позже, были даже были идеи открыть аналогичный проект, но тогда своими проектами времени заниматься не было. Нам хорошо платили просто за то, что мы у них есть, а мы в ответ качественно выполняли свою работу. Предложили им написать собственное решение для управления всем их электронным добром из одной админки, чтобы не надо было кучу раз переавторизовываться, путаться в проектах, короче от всех проблем отнимающих время. Нам дали зеленый свет и 3 месяца на разработку.
Так родилась основа для Web Apps. Тогда мы этого еще не знали, а только проектировали решение для взаимодействия любого количества серверов под управлением одного сервера. Разработали универсальный способ связи между серверами, позволяющий удаленно производить инсталяции, и обновления, а не только редактирование контента. Мы испытали кайфовое чувство по завершении работы, когда ты сидишь, пишешь код в текстовом поле, нажимаешь кнопку сохранить и все подконтрольные компьютеры, на которых лежит всего один наш файлик уже имеют этот код и исполняют по требованию.
Вложились мы в два месяца, оставался месяц на разработку системы управления. Даже сорвав сроки ничего страшного бы не произошло, нам уже было что показать. И задумались над XMLHttpRequest, использовать его или нет в самих проектах. И тогда мы случайно увидели, что все сайты в браузере, как бы это сказать правильно, отличаются от интерфейсов операционных систем только тем, что в сайтах происходят переходы по ссылкам, а операционки работают работают гладко, без мерцаний, подбрасываний экранов и «помнят» обо всех запущенных приложениях, с легкостью ими оперируя. Дальше можно ничего не рассказывать о годах раздумий, кодинга, рефакторинга, а можно сразу перейти к тому что есть на данный момент. А это аналог операционной системы в браузере, позволяющий всё, что только браузер может из себя выжать, отличающийся от компьютерных операционных систем только несколькими характеристиками.
Хочу так же заметить, что каждая строчка кода написана вручную, не использовалось ни одно стороннее решение, будь то библиотека, фреймворк или концепция.
Назвать проект было решено просто «сетевая операционная система», она же по сути Web Apps, так как это среда контроля работы неограниченного количества приложений, работающая только при подключении любого электронного устройства с браузером к сети интернет, и такой еще в природе не было. В сети её нет по многим причинам, в конце все эти причины опишу. Всё работает на наших компьютерах. Продукт представляет из себя очень тонкий клиент. Встроенная библиотека менее 100 Кб кода javascript покрывает почти все потребности, для создания интерфейсных приложений. Если бы у вселенной был интерфейс доступа ко всем её объектам, он бы выглядел примерно так же. Все приложения состоят из крошечных, независимых кусочков, взаимодействующих между собой. Больше не надо продумывать сложную логику для всего приложения в целом, этим умело занимается ядро, выполняя половину работы программистов. В век сетей, когда почти любое приложение требует подключения к интернету, это самое простое решение. Всё равно в какой оперционной системе разработан софт и на каком языке программирования, если он не будет работать без интернета.
Делает всё это несколько новых приёмов в программировании, а так же несколько техник, которые считаются у программистов плохим тоном в контексте разрабатываемых ими систем. Тег больше не является частью представления. Это очень мощный инструмент, потенциал которого не видно на первый взгляд. Теперь этот тег является частью серверного кода, который реализован классом с десятком методов. А так же появился новый массив системных переменных, который аналогично суперглобальному массиву изменяется в зависимости от состояния приложения и участвует как в формировании тега , так и помогает не писать кучу ненужных вычислений, контролирующих поведение приложений.
На данный момент реализована только среда для написания приложений на языке PHP. Если сконфигурировать веб сервер так, что он будет обрабатывать несколько языков программирования и работать с несколькими СУБД, модифицировать ядро на работу приложений на любых языках не составит проблемы. Язык программирования вообще не имеет значения, так как клиентская часть выглядит одинаково какой бы сервер не обрабатывал запросы. PHP как самый распространённый и легко настраиваемый язык, позволит дать попробовать на ощупь систему в работе огромному количеству людей и получить большую обратную связь и доработать проект до требуемого функционала. Порог вхождения в методологию минимальный, приложения сможет писать даже школьник. Javascript код писать практически не требуется для написания SPA приложений на php, пишется только серверный код. Сервер сам превращает «сайт» в SPA, если следовать документации.
Работа начинается с регистрации. Каждый участник системы получает архив с несколькими крошечными файлами и свой регистрационный ключ. Ключ дает право пользоваться системой. Если удалить ключ из базы разрешенных, этот участник больше не сможет пользоваться софтом. Распаковав архив и скопировав его на сервер, или на локалку, начинается инсталяция необходимых файлов. Нагрузка на сервер контролируется особой системой. Написав файл со списком серверов и числом участников на сервере балансируется нагрузка. Если поднять 10 серверов по 1 000 человек на каждый, а зайдет 11 000 человек, первые 10 000 распределяться по 10-ти серверам, а еще тысяча будет стоять в очереди, подавая сигнал администраторам о недостаточности мощностей. Софт который работает от сети интернет не имеет права «упасть» или подвисать, поэтому и используется данная система контроля нагрузки. Нужно освободить сервер от пользователей вообще — просто написать что можно 0 человек и их всех переподключит на другой сервер. Ядро системы обеспечивает лишь контроль корректной работы приложений и всё. Все файлы приложений, работают на мощностях пользовательского сервера/хостинга. Система лишь генерирует массив данных, который используется кодом приложения для его правильной работы. Если ядро находится в локальной сети с , задержка в работе интерфейсов полностью отсутствует, всё происходит мгновенно, как на мощном домашнем компьютере, визуальной разницы нет.
После установки файлов для работы клиента, открывается рабочий стол. Панель задач и пустой, без каких либо предустановок рабочий стол. В репозитории несколько тестовых приложений, показывающих как сложные вещи просто реализуются. Панель задач «помнит» состояния всех запущенных приложений, переключаясь между ними получаете в точности то, что видели последний раз, в тех же положениях скроллов, данных в текстовых полях, даже если вы их забыли сохранить, ничего не упускается. Раньше систему можно было запаролить и войдя снова увидеть всё как оставалось в прошлый раз. Это как режим «сон» компьютера. Прямо сейчас система аутентификации модифицируется до такой степени, что кроме email`а при регистрации по сети ничего не передается. При авторизации даже email не передается. Мы совсем недавно разрабатывали такой способ авторизации и хотим его здесь использовать.
У приложений есть слыжбы. Службы делятся на 2 типа. Те которые можно закрыть и те которые не закрываются, если не выключить их принудительно. При открытии приложений запускаются их службы, если служба первого типа, такие завершают свою работу при закрытии браузера, выхода из аккаунта, или просто обновления страницы. Службы второго типа работают всегда, когда приложение открыто или свернуто, и подгружаются при старте сеанса. Только закрыв приложение можно закрыть и службу.
Дизайн редактируется, всё можно настроить как нравится. Там и настраивать особо нечего, высота и фон панели, фон иконок приложений в панели, активной и неактивных, и стиль ярлыков приложений рабочего стола. Всё что связано с дизайном самих приложений, это уже заботы разработчиков приложений.
Реализована и готова к работе только версия для ПК. Прорабатывалось еще две версии, это версия для мобильных устройств и версия для терминалов.
Применение в сфере мобильных устройств приложений такого типа, позволит запускать одновременно десятки приложений на самых слабых устройствах, хоть никогда их не закрывая, и при этом практически не создавать нагрузки. Станет неважно за 5 000 телефон или за 50 000, ведь вычислительные ресурсы для работы устройства можно черпать со своего сервера, а на экран мобильного устройства просто будет приходить готовый результат. Мы так же думали, что данный подход можно использовать для создания ОС самого устройства, при чем варианта работы два. Один вариант, это когда мобильник автономен и вычислительное ядро является его частью. Другой вариант, это когда мобильник работает от сети интернет. Плюс тут заключается в том, что такой телефон нет смысла воровать, потому что он легко выключается удаленно, превращаясь в кусок негодного пластика и микросхем, при этом будет стоить копейки, так как свою вычислительную мощность он берет с какого-то сервера. Играть на таком получится только в те игры, которые тянет браузер, так что это скорее бизнес модель аппарата, целесообразно это или нет — спорно, просто выражаю мысли. Возможно, что некая компания в сфере интернет услуг будет заинтересована в выдаче таких аппаратов сотрудникам, со всеми необходимыми для их работы приложениями.
А вот применение в сфере терминалов может развить эту отрасть. Сейчас основная задача терминалов принимать наличные. С применением данного программного обеспечиния, терминализовать можно множество отраслей, заменив мониторами большинство функций, которые выполняет обслуживающий персонал. Пока терминалы используются редко, в основном в больших компаниях, при работе с потоком клиентов, чтобы хоть частично разгрузить очереди. Данное ПО позволит управлять тысячами терминалов, в режиме реального времени обновлять программное обеспечение. Специалистам по обслуживанию даже не потребуется выезжать на точку, всей сетью терминалов станет возможно управлять с одного компьютера.
В конце концов можно использовать это для основы движка для создания сайтов, чтобы делать удобные и легковесные сервисы.
Теперь о плохом, не всё так гладко.
1. На данный момент есть одна большая проблема, которую мы не можем решить сами. Это права пользователей. Сейчас каждому приложению создаётся своя папка на сервере, туда заливаются файлы приложений. Конечно перед установкой какого либо приложения, если оно не является платным, можно прочитать весь код. Для разработчиков это не проблема, они всё могут перепроверить перед установкой. А для обыденного пользователя эта билиберда ни о чём не говорит. Хакнуть пользователя, установившего зловредное приложения и выпотрошить его полностью — элементарно. Нужна какая то система управления правами приложений на сервере, чтобы каждое приложение не могло выйти за пределы своей папки. Помогут любые советы на этот счёт, возможно всё проще чем кажется и проблемы нет, кто знает. Возможно есть смысл разрабатывать подобие антивируса, который на этапе создания приложения будут ругаться на сомнительные участки кода.
2. Мы понятия не имеем что с этим делать, мы не бизнесмены, а программисты, запускать и развивать проект проблема. Неоднократно мы пытались найти помощи инвесторов, но результата не было. Одни просто не верят что в компьютерной отрасли может что-то поменяться, других интересуют только цифры прибыли и сроки. Третьи приглашают в Москву выступить с докладом. Четвертые задают такие вопросы, на которые мы не знаем ответов. Сесть в автобус и ехать в Москву, вот так с бухты барахты, с ноутбуком на плече — глупо. Если с одним инвестором не получится, надо останавливаться там и искать следующего. Надо где-то жить и работать, то есть нам надо искать в Москве сначала работу и жильё? Поэтому и решили написать тут статью, может тут найдем помощь. Быть может кто-то заинтересованный с подобном софте напишет грамотную презентацию, как правильно представлять проект, какую отдачу можно получить от проекта. Приветствуется любая помощь.
3. Некоторые люди, знающие о проекте, предлагают этот алгоритм запатентовать. Тут мы вообще профаны что и как делается. Запустить приложение и показать в работе не сложно, а вот надо регистрировать юрлицо или нет не ясно. Надо ли где-то регистрировать код или авторское право? Может это вообще сделать открытым исходным кодом и голову не морочить? Вопросов на которые нет ответов — много. А еще нами движет патриотическая нотка, это придумано в России и мы не хотим отдавать такое за бугор, чтобы нам это оттуда продавали.
На самом деле что написано выше о 10 годах разработки частично не правда. Проект на стадии «сделали и забыли» уже пару лет. Мы не то что забыли, мы забили, сейчас каждый из нас работает по своему, не все даже в сфере разработки. Открывая некоторый код приходится заново перечитывать и вдумываться что мы там написали, заново идти по цепочке алгоритма чтобы найти нужное место для редактирования. Но всё равно это проект запустить надо рано или поздно. Будет жаль если проект умрёт так и не родившись, надеюсь что с вашей помощью дело сдвинется в мертвой точки.
Автор: Железный человек
