Продолжительность жизни создаваемого cgi-приложения...
=) Хао пипл. Мучает меня такой вот вопрос: что принимать за предел/срок годности приложения, подходя к разработке cgi приложений или продумывая структуру базы данных. К примеру, просто пример из воздуха, созрел новый стандарт SQL предлагающий новый революционный подход по всем параметрам более выгодный нежели реляционный, он свежий, но динамично развивается, и через 2-3 года все другие диалекты sql просто вымрут. Как быть программируя бд если новый стандарт sql есть, но реализаций еще нет? Предусматривать ли возможность работы создаваемого приложения еще на 10 лет вперед, или же ограничиться примерной датой окончательного становления sql новизны, с запасом. А там уж пусчай заказчик заказывает все заново?+)
Ну, пример конечно не лучший. Но все же. Каким будет оправданный срок работы (надежной работы имеется ввиду) для движком e-shop'ов, рейтинговых систем, форумов, гостиничных ресурсов и т.п. Для индивидуальных работ, а не постоянно поддерживаемой и продвигаемой монстро-cmf.
Ясно что от заказчика внятного ответа на этот счет ждать не приходится, все хотят жить вечно, быть самыми популярными, востребованными и передавать свой бизнес каким-нибудь там детям из поколения в поколения сквозь века и тысячелетия=) Этот вопрос нужно решать самому, и как в таком случае быть?
Конкретных советов не нужно, просто интересно узнать каким должен быть примерный ход мысли в таком деле, если учесть что работаем с cgi и юзаем perl,php,java,c,cpp и (отдельно) со всяческими субд. Может в тени каких-то языков даный вопрос имеет какие-нибудь оригинальные подводные камни=)
---
Хотя нет, давайте и частные случаи рассмотрим, кто готов поделиться опытом?
---
Вот для примера. До выхода php4 люд пользовал get/post параметры как глобалы и даже наверное не догадывался о том, что в 4-ке введут такой ini-параметр как gpc_globals (ныне register_globals), расширят его и вскоре отключат по умолчанию и зарекомендуют "больше его не включать". Сам конечно не знаю, но думаю мало кто тогда предусмотрел такой поворот событий и к 4.2.0 код перестал работать.
Совсем не хочу кодить под 5-ый php, но 4-ый когда-нить да вымрет. На какие сроки рассчитывать=)
ps: только не мусорьте попусту:D
Ну, пример конечно не лучший. Но все же. Каким будет оправданный срок работы (надежной работы имеется ввиду) для движком e-shop'ов, рейтинговых систем, форумов, гостиничных ресурсов и т.п. Для индивидуальных работ, а не постоянно поддерживаемой и продвигаемой монстро-cmf.
Ясно что от заказчика внятного ответа на этот счет ждать не приходится, все хотят жить вечно, быть самыми популярными, востребованными и передавать свой бизнес каким-нибудь там детям из поколения в поколения сквозь века и тысячелетия=) Этот вопрос нужно решать самому, и как в таком случае быть?
Конкретных советов не нужно, просто интересно узнать каким должен быть примерный ход мысли в таком деле, если учесть что работаем с cgi и юзаем perl,php,java,c,cpp и (отдельно) со всяческими субд. Может в тени каких-то языков даный вопрос имеет какие-нибудь оригинальные подводные камни=)
---
Хотя нет, давайте и частные случаи рассмотрим, кто готов поделиться опытом?
---
Вот для примера. До выхода php4 люд пользовал get/post параметры как глобалы и даже наверное не догадывался о том, что в 4-ке введут такой ini-параметр как gpc_globals (ныне register_globals), расширят его и вскоре отключат по умолчанию и зарекомендуют "больше его не включать". Сам конечно не знаю, но думаю мало кто тогда предусмотрел такой поворот событий и к 4.2.0 код перестал работать.
Совсем не хочу кодить под 5-ый php, но 4-ый когда-нить да вымрет. На какие сроки рассчитывать=)
ps: только не мусорьте попусту:D
Цитата:
Originally posted by Shiizoo
К примеру, просто пример из воздуха, созрел новый стандарт SQL предлагающий новый революционный подход по всем параметрам более выгодный нежели реляционный, он свежий, но динамично развивается, и через 2-3 года все другие диалекты sql просто вымрут.
К примеру, просто пример из воздуха, созрел новый стандарт SQL предлагающий новый революционный подход по всем параметрам более выгодный нежели реляционный, он свежий, но динамично развивается, и через 2-3 года все другие диалекты sql просто вымрут.
А что за стандарт? Нельзя ли ссылочку?
Да эт так, из воздуха придумал, для наглядности. Пока все кажется спокойно:D
Цитата:
Originally posted by Shiizoo
Да эт так, из воздуха придумал, для наглядности.
Да эт так, из воздуха придумал, для наглядности.
Тогда это паранойя. Нельзя предусмотреть совместимость со всем и вся. Тем более на уровне проектирования. Новые технологии всегда означают вначале переосмысление проблемы, потом переписывание кода. На практике же работающие приложения никто переписывать не хочет. Поэтому и пользуемся старыми.
Ну, ключевым словом в первом топике, кторый стал этим и была паранойя. Имелось ввиду планирование в меру=)Все-таки какой-то софт работает годами, а какой-то дохнет при легких изменениях в апи осей и т.п. и т.д.=)
Такой момент, работа со знаковыми целыми идет быстрее, чем с бесзнаковыми. Но выбор знакового типа означает очередное ограничение (ну например в том же форуме, для полей счетчиков и прочей дряни). Стоит ли предусматривать возможность работы форума при некоторым количестве миллионов зарегистрированных пользователей? А дорастет ли он до такого уровня? Такие моменты можно и самому решить, но все ж любой кодинг им кишит и там и сям, если приглядется, а не прямолинейно кодить что-то, что в итоге вырастет в весьма ограниченное творение=)
Ну и т.п. и т.д., долбаная паранойя, достала=))
Такой момент, работа со знаковыми целыми идет быстрее, чем с бесзнаковыми. Но выбор знакового типа означает очередное ограничение (ну например в том же форуме, для полей счетчиков и прочей дряни). Стоит ли предусматривать возможность работы форума при некоторым количестве миллионов зарегистрированных пользователей? А дорастет ли он до такого уровня? Такие моменты можно и самому решить, но все ж любой кодинг им кишит и там и сям, если приглядется, а не прямолинейно кодить что-то, что в итоге вырастет в весьма ограниченное творение=)
Ну и т.п. и т.д., долбаная паранойя, достала=))
Цитата:
Originally posted by Shiizoo
Имелось ввиду планирование в меру=)Все-таки какой-то софт работает годами, а какой-то дохнет при легких изменениях в апи осей и т.п. и т.д.=)
Имелось ввиду планирование в меру=)Все-таки какой-то софт работает годами, а какой-то дохнет при легких изменениях в апи осей и т.п. и т.д.=)
Метод только один - проектирование по Бучу, декомпозиция по Вирту, алгоритмы по Кнуту, и т. д. Где отошел от классики - при первой же переделке придется переписывать.
А вообще, идея независимости от БД - одна из мега-идей, постоянно будоражащая умы разработчиков. Польза от тех или иных ее реализаций, что такая же, как от многоплатформенности в стиле Qt или Java: пользоваться в принципе можно, но чур меня! :D
Цитата:
Originally posted by Shiizoo
Такой момент, работа со знаковыми целыми идет быстрее, чем с бесзнаковыми.
Такой момент, работа со знаковыми целыми идет быстрее, чем с бесзнаковыми.
Ты еще такты процессора посчитай. Для программирования сетей и БД - наипервейшая задача, ибо сеть или база работают быстрее.
Да ну её в болото. Хочу в системное программирование, считать эти самые такты=) Кто бы научил:D Человеки, какую литру читать, а? Тяжко безлапой ящчегице мечтать о небесах:D