[жж] о веб-разработке, пара мыслей вслух

Ты прав.

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

По уму оно больно уж тяжело и монструозно получается. Посмотри как пример портальные java-решения типа websphere portal.

Всё правильно, веб2.0 не нужен. По большому счёту веб вообще не нужен, вместо нужного из веба нужно сделать вики.

Как по мне, так большинство проблем в мире ПО от того что клиенты хотят «странного».

Да. Поэтому rails engines во все поля.

Веб2.0 в текущем виде — это два тезиса:

• интеграция всего со всем (хотя, по идее, это достаточно новая идея, я бы сказал, веб2.5 — все делают не столько сайтики для чтения человеками, сколько API для взаимодействия с другими сервисами)
  
• владелец сайта зарабатывает на контенте, который ему генерят пользователи, совершенно бесплатно, а то и за свои же кровные.

Похэпистам частенько трудно понять, что какой-то сервис не обязан быть сайтом и публиковаться через HTTP, есть уйма других способов взаимодействия, причем они используются уже сегодня. Например, какие-нить локальные службы необязательно должны стучаться через HTTP (видал я вещи, типа по крону через lynx(!) запрашивается из локалхоста некий URL, по которому происходит какая-то рутинная зачистка мусора из базы).

А потом это недопонимание кочует в ту же джангу, рельсики.

да веб с самого рождения помойка, и техническая реализация у него говеная, начиная с HTTP и HTML, и тянет к себе всяких обезъян, и языки там популярны типа PHP и подобного барахла :)

хотя сама идея годная

надо бы реализовать свой веб, с БШ, на основе TeX (вместо HTML) и stateful-протоколом вместо HTTP :)

> Как по мне, так большинство проблем в мире ПО от того что клиенты хотят «странного».

Беда даже не в том, что они странного хотят, а в том, что потом они не знают, что с этим странным делать. Что, мало клиентов со своими дурацкими стартапами, которые совершенно не понимают, как именно они будут окупать расходы и получать из этого прибыль?

Мы-то можем сделать странное, оно даже работать будет. Да толку вот.

Полностью согласен. Особенно запомнился один случай.
При разработке одного проекта начальство нафантазировало кучу лишних фич, которые на практике не могли даже быть полезными. Разрабы втихаря их выпилили, после того когда увидели что операторы приложения этим не пользуются и вообще оно им не нужно. При этом приложение успело проработать около 2-х лет. Пропажи никто и не заметил.
Спрашивается, зачем было сунуть нос куда не нужно, портить людям жизнь и тратить _свои_же_ деньги?

>Это веб-программизм настолько вредит здравому смыслу, или мне шибко странного хочется?

Это просто избытки скриптового программирования и недоученного предмета программирования в университете. Основным двигателем проблемы является то, что код ненадо компилировать вочтолибо, и так заработает. Следовательно разработчик думает так: если кто-то захочет взять мои наработки пусть смотрит код. Стандартов никаких нет и в этом случае получается, что каждый создаёт себе стандарт. Мне например очень ненравится куча классов в современных веб приложениях. Да оно-то может и ООП и там сиськи-плюшки. Но блин 100500 кратное наледования для вывода строки из базы это оффтоп. А ещё хуже если не используюстя какие либо namespace и т.д.

Как-то так.

> При разработке одного проекта начальство нафантазировало кучу лишних фич, которые на практике не могли даже быть полезными. Разрабы втихаря их выпилили, после того когда увидели что операторы приложения этим не пользуются и вообще оно им не нужно. При этом приложение успело проработать около 2-х лет. Пропажи никто и не заметил.
Спрашивается, зачем было сунуть нос куда не нужно, портить людям жизнь и тратить _свои_же_ деньги?

За эти ненужные фичи хоть заплачено было?

Обидно же. Код запилили, выпилили и денег не взяли.

> Мне например очень ненравится куча классов в современных веб приложениях.

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

>Например, какие-нить локальные службы необязательно должны стучаться через HTTP (видал я вещи, типа по крону через lynx(!) запрашивается из локалхоста некий URL, по которому происходит какая-то рутинная зачистка мусора из базы).

кстати, а как-бы сделали вы?

> За эти ненужные фичи хоть заплачено было?
Там все веселей. Заказчик, он же начальник. А проект для внутреннего использования его компанией. Вот разрабы когда увидели приложение в деле поняли что не нужно и каким приложение должно было бы быть. А не таким каким от них его требовали.
Классический пример как человек придумывает ненужный функционал без необходимости.

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

> кстати, а как-бы сделали вы?

У меня была бы библиотека общего пользования, к ней фронтэнд для командной строки и веб-фронтэнд.

Не слишком-ли сложно для того, что-бы каждые N минут запустить php-скрипт?

что-бы каждые N минут запустить php-скрипт?

php /path/to/script.php

Зачем его через http то дергать?

А всё потому что SQL.</troll>

> Зачем его через http то дергать?

Наверное, чтобы параметров передать.

>Вот нет же, чтобы выполнить такие компоненты в виде реюзабельных компонент

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

Однако, реализовать _стандартные_ типовые решения «форум», «блог», etc. — легко. Но не востребовано.

>кстати, а как-бы сделали вы?

Ну, например, у меня пофиг, через HTTP обращение или прямое, скриптом. Есть отдельно инициализируемая объектная библиотека, а уж кто её дёрнет, точка входа с http или скрипт — разницы никакой.

Так что по http всякие служебные скрипты дёргаю только на всяких говнохостингах, где нет cron'а :)

>На руби есть гемы в которых в основном компоненты не прибиты друг к другу. Да и на том же похапе есть pear.

Вопрос не в библиотеках, а в готовых типовых взаимно интегрированных решениях.

>Не слишком-ли сложно для того, что-бы каждые N минут запустить php-скрипт?

Нет, если требуется более одного проекта типа «визитная карточка».

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

>А если ты имеешь в виду интеграция готового форума, блога и прочего между собой

Именно так.

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

Да, естественно, подразумевается, что они на одном фреймворке :)

…

Хотя, например, свой фреймворк я делал в первую очередь для интеграции с готовыми решениями, так что он легко цепляется к любому стороннему решению. Но вот клеем между несколькими сторонними решениями работать уже почти не получается. Например, без ломания сторонних решений фиг совместишь систему авторизации. Легко задействовать чужую систему авторизации в своём фреймворке, но без хаков нереально совместить, ну, скажем, авторизацию Drupal и iPB :)

Самое весёлое в портале - он с нуля всё равно ничего не умеет. Всё равно программировать :)

>Зачем его через http то дергать?

а, ну да. точно. Ну наверное для получения единой точки входа. Хотя я-бы использовал wget.

Zope был славен бесшовной интеграцией приложений (конечно если не имбецил писал)

Веб вообще говно, использующее вещи не по предназначению.

> Мне например очень ненравится куча классов в современных веб приложениях. Да оно-то может и ООП и там сиськи-плюшки. Но блин 100500 кратное наледования для вывода строки из базы это оффтоп.

Внезапно, согласен.

Я к тому, что программы через браузер — ущербная идея. HTML не для этого создавался, потом просто костылями оброс.