vitus_wagner (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
vitus_wagner) wrote2008-04-11 11:54 am
vitus_wagner) wrote2008-04-11 11:54 am
Entry tags:
Coder must die
Тут Алексей Печников замучал меня вопросами, почему для StillLife выбрана именно такая архитектура.
Поэтому я решил признаться в своем тайном замысле. Основная цель - убить web-кодера, как профессию.
Первым пристрелочным выстрелом в эту сторону был Communiware. Это был очевидный перелет. Концепция "информационного супа" предложенная для Коммунивера Андреем Акопянцем настолько велика и могуча, что освоить её в совершенстве могут только отдельные гении вроде![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
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, но с перетаскиванием её будут некоторые проблемы - потребуются специальные срества импорта/экспорта. Да и работать она будет неэффективно, так как она будет вынуждена на каждом сервере не использовать именно те возможности, которыми он наиболее силён - из-за отсутствия этих возможностей в других серверах, совместимость с которыми поддерживается.
Поэтому я решил признаться в своем тайном замысле. Основная цель - убить 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, но с перетаскиванием её будут некоторые проблемы - потребуются специальные срества импорта/экспорта. Да и работать она будет неэффективно, так как она будет вынуждена на каждом сервере не использовать именно те возможности, которыми он наиболее силён - из-за отсутствия этих возможностей в других серверах, совместимость с которыми поддерживается.
no subject
no subject
Кэширование на стороне сервера - это не магическая пуля, а технология, которой надо уметь пользоваться.
Проблема в том, что и правильная структура БД, и кэширование - это технологии, которые В МОЗГАХ пользователя не укладываются. Причем настолько что при найме web-разработчика он не может адекватно оценить насколько эти технолгии укладываются в мозгах web-разработчика. И в большинстве случаев там они не укладываются тоже.
Проблема на самом деле заключается в том, что для 90% Web-проектов не нужны ни базы данных, ни динамическая генерация страниц.
Я как раз пытаюсь разработать альтернативную парадигму, в которой нету этих сложностей. Её можно назвать WYSIWYS - What you store is what you see.
Communiware была попыткой реализовать технологию WYSIWYM - What you store is what you mean. Но это оказалось неудачным. Большинство пользователей мыслят настолько невнятно, что не могут объяснить системе что они mean.
no subject
no subject
Меня интересуют маленькие сайты, которые совершенно не застрахованы от всплеска посещаемости - ну взяли и опубликовали на новостном ресурсе с миллионами посетителей в день ссылочку.
no subject
no subject
no subject
Хороший же движек юольшого сайта может прекрасно обслуживать и маленький.
no subject
no subject