Coder must die

[vitus_wagner]

Тут Алексей Печников замучал меня вопросами, почему для StillLife выбрана именно такая архитектура.

Поэтому я решил признаться в своем тайном замысле. Основная цель - убить web-кодера, как профессию.

Первым пристрелочным выстрелом в эту сторону был Communiware. Это был очевидный перелет. Концепция "информационного супа" предложенная для Коммунивера Андреем Акопянцем настолько велика и могуча, что освоить её в совершенстве могут только отдельные гении вроде ailev. Ну и ресурсов тоже кушает будь здоров.

Это не то, что нужно отдельному юзеру.

Поэтому StillLife в значительной мере Communware наоборот. Если в Communiware в базе хранились не только данные, но и программы их представления (шаблоны), то в StillLife базы данных нет вообще, если не считать пары DBM-ок, используемых для аутентификации пользователей.

Если язык шаблонов Communiware был весьма мощным декларативным языком с условными конструкциями, обработкой список и т.д., то в StillLife шаблоны представляют собой обычный html всего лишь с некоторыми предопределенными именами классов.

В общем, классическая попытка взять цель в вилку.

Понятно, что получится недолет. Даже сейчас видны целые классы сайтов, реализация которых на базе концепции StillLife принципиально невозможна, например Internet-магазины. Web-форум - это предел интерактивности, которого можно добиться на базе такой концепции. Именно поэтому разработка StillLife начата именно с форумного движка. Дальнейшее - блоги и средства управления контентом традиционного сайта - будет проще.

Основное, что лежит в основе - антитеза концепции, выдвинутой ailev лет 6-7 назад "Сайт - это программа".
Как раз эта концепция, которая в общем-то в то время носилась в воздухе, приводит к тому, что вокруг WWW кормится армия криворуких кодеров. Раз сайт это программа (при этом каждый сайт - отдельная, уникальная программа), каждому сайту нужен программист. Хороших программистов на все сайты не напасешься, значит большая часть сайтов, в том числе и интересных содержательно, будут написано плохими программистами, а следовательно будут плохими, неудобными для пользователя программами.

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

Примерно в этом направлении сейчас двигаются Google, SixApart и другие подобные крупные сервисы.
Но они - злобные проприетарщики. Хотя сейчас очевидно, что создать хорошее web-приложение без использование OpenSource технологий практически невозможно, они ухитрились обойти GPL посредством исполнения программ только у себя на сайте. Раз пользователь не получает исполняемой копии программы, он не вправе требовать и доступа к исходным текстам, даже если 90% кода - GPL.

Кроме того, решения применяемые LJ, Google и другими крупными сервисныи компаниями в WWW требуют соответствующей аппаратной базы. Именно этим объясняется незначительный успех клонов ЖЖ, базирующихся на его коде. Вербицкий может взять исходники ЖЖ, которые Фитцпатрик честно открыл, но у него нету и не может быть денег для создания датацентра, аналогичного калифорнийскому датацентру ЖЖ. Поэтому Vendor Lock In в классическом виде.

Для полноценной реализации концепции "сайт - это документ", требуется программа обработки этого документа, способная выполняться на любом, доступном пользователю компьютере - будь то shared hosting, будь то домашний компьютер с широкополосным подключением к интернету. Лучше конечно, иметь несколько разных программ, адаптированных к разным средам выполнения, но работающих с одинаковым форматом документа. Именно работающих с одинаковым форматом документа. Поэтому столь распространенные нынче в веб-строительстве РСУБД не годятся. Можно создать схему БД, которая будет работать в mySQL, PostgreSQL и Oracle, но с перетаскиванием её будут некоторые проблемы - потребуются специальные срества импорта/экспорта. Да и работать она будет неэффективно, так как она будет вынуждена на каждом сервере не использовать именно те возможности, которыми он наиболее силён - из-за отсутствия этих возможностей в других серверах, совместимость с которыми поддерживается.

Comments

[vitus_wagner]

Да запросто. Если это будет на своем месте (в тех же интернет-магазинах, к примеру) то почему бы и нет.
Тем более что в выбранном инструментарии уже есть обобщенный интерфейс DBI.

Проблема существующих движков не в том, что они используют БД. А в том, что они пытаются распространить на сайт концепцию хранения данных в БД. Вот тут она начинает предъявлять свои требования и налагать свои ограничения, а потом админы хостингов плачут "Вот, яндексбот пришел, сайт за-DoS-ил".
Думаю, что если ко мне на StillLife яндекс-бот в 50 параллельных запросов придет, я и не замечу (разве что канал выжрет).

[metaclass.livejournal.com]

Странно, БД вообще-то в норме должны до сотни запросов на запись в секунду выполнять (мелкое бухгалтерское приложение у меня столько съедает), а уж чтение так и вообще летать должно.
Хотя PHP и MYSQL я в таких условиях не испытывал, но думаю, что для веба оно должно быть еще более производительным, там же количество пользователей формально ничем не ограничено, в отличие от всяких интранетовских клиент-серверных приложений.

[vitus_wagner]

Запрос запросу рознь. "Сотни запросов на запись в секунду" - это OLTP. Там и запросы простые, и структура БД именно под эти запросы тщательно оптимизирована. А на сайтах достаточно часто возникают запросы, более характерные для OLAP.

Опять же сотня запросов это не так много. Вот в Communiware, например, включение профайлинга дает на главной странице Либертариума табличку которая нийига в ЖЖ-шный коммент не лезет. Там, правда, не показывают SQL-текст запросов (и без администраторских прав на конкретный сайт - не покажут) но там тоже много интересного увидить можно.

[metaclass.livejournal.com]

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

[slav0nic.livejournal.com]

>>Total execution time: 30.293121 sec

всё-таки пограммисты пока что поживут;)

[vitus_wagner]

Пять лет уже живут. Я их того проекта пять лет назад ушел. Причем, похоже, с тех пор базу ни разу не оптимизировали и железо не апгрейдили.

[potan.livejournal.com]

Эта проблема может быть решена кешированием на стороне сервера.

[vitus_wagner]

Как показывает практика - не может она быть решена таким образом.
Кэширование на стороне сервера - это не магическая пуля, а технология, которой надо уметь пользоваться.
Проблема в том, что и правильная структура БД, и кэширование - это технологии, которые В МОЗГАХ пользователя не укладываются. Причем настолько что при найме web-разработчика он не может адекватно оценить насколько эти технолгии укладываются в мозгах web-разработчика. И в большинстве случаев там они не укладываются тоже.

Проблема на самом деле заключается в том, что для 90% Web-проектов не нужны ни базы данных, ни динамическая генерация страниц.

Я как раз пытаюсь разработать альтернативную парадигму, в которой нету этих сложностей. Её можно назвать WYSIWYS - What you store is what you see.
Communiware была попыткой реализовать технологию WYSIWYM - What you store is what you mean. Но это оказалось неудачным. Большинство пользователей мыслят настолько невнятно, что не могут объяснить системе что они mean.

[potan.livejournal.com]

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

[vitus_wagner]

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

[potan.livejournal.com]

А зачем делать разные движки для больших и для маленьких сайтов?

[vitus_wagner]

Зачем выпускать одновременно автомобили "Ока" и "Камаз". Пусть все на КАМАЗах ездят.

[potan.livejournal.com]

ТТХ КАМАЗа не позволяют ему полностью заменить Оку. В частности, его вес не все дороги могут выдержать.
Хороший же движек юольшого сайта может прекрасно обслуживать и маленький.

[vitus_wagner]

Вообще-то в случае КАМАЗА главное не дороги, которые в норме все же КАМАЗ выдерживают, а прожорливость. И у движков, способных обслужить большие сайты тоже прожорливость соответствующая. Причем требования не только к процессору и памяти, но в первую очередь - к квалификации обслуживающего персонала. Либо надо тогда делать shared CMS хостинги, где команда сисадминов обслуживает движок, который тянет тысячи независимых сайтов. Мы пробовали такое на Communiware делать. Продается, прямо скажем, плохо.

[ilya-portnov.livejournal.com]

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

[avnik.livejournal.com]

В 21 веке -- писать запросы к базе через DBI руками? Это же все равно что писать веб сервер на ассемблере. Есть же ORM'ы. Хранить (и манипулировать) надо объекты. А как они там хранятся -- в таблице, в xml или в plain text -- это уже 10е дело и выбрать можно тот способ хранения который оптимален для задачи.

[vitus_wagner]

Объекты - очень опасная вещь. Это слишком универсальная абстракция. С одной стороны она достаточно сложна, чтобы ей НЕ МОГ грамотно пользоваться средний разработчик - грамотный ООД требует слишком квалифицированного архитерктора, с другой - она кажется слишком простой и доступной.

Наибольшую опасность в ООП представляет собой неграмотный code reuse - попытка использовать готовый объект, который чуть-чуть не подходит к требованиям задачи. Работать вроде как бы и работает, но мало того, что глючит и тормозит, так еще и накладывает на разработчика неоправданные ограничения.

[avnik.livejournal.com]

не более опасная чем SQL.
Назовите их как-то по другому -- в джанго такие объекты называются моделями. Их и наследовать нельзя (по крайней мене в нынешней реализации) да и ситуация когда это надо мне встречалась только один раз.

А уж сколько веселого можно на SQL нагородить -- injection например.

[vitus_wagner]

Да, пожалуй, стоит в качестве интерфейса к БД смотерть в сторону QBE. Вот QBE в простых случаях в голове у юзера вполне укладывается. А в сложных - функционально эквивалентен SQL. Правда, работать с полной реализацией QBE мне не приходилось. В той реализации, с которой я лет пятнадцать назад имел дело, (Borland Paradox 4.0) не была реализована операция связывания таблицы с самой собой.

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