тогда научите как перемещаться по сайту без навигации
вы считаете что навигация это мусор или она очень нужна в версии для печати?
С разработкой дизайна. Естевенно с пожеланиями клиента. Цена дана для моего видения проекта. Если мои взгляды и ваши расходятся сильно, то и цыны будут меняться.
Согласитесь, Ваше ТЗ очень-очень краткое.
Непоследнее значение в цене будет иметь требование к методам разработки и хостер.
извените за офф.. а разве читать такие шрифты удобней? Меня сильно коробит, когда текст на бумаге или печати с засечками.
я стараюсь делать так, что версия для печати имеет больше отличий чем просто подавленные картинки и оформление.
Salov-Nikolaj, http://company.yandex.ru/technology/server/
PartW, если убрать
и
то на самописанном дыижке 3-5тыс$, тендер + вики будут стоить столько-же...
Цыфры реального проекта.
sokol_jack, ощущение такое, что мы говорим не о крошечной сапе, а хотябы о рамблере. Перестаньте. Какие миллионы... Вы о чем. Конечно, можно и столько данных в базу накидать, но зачем?
база в UTF в 3-4 раза больше. Строковые операции работают значительно медленнее, даже на сях, неговоря уже о тормозном пхп. Объем итоговых страниц, отдаваемых юзеру, увеличивается на 10-30%.
Вопрос, а что мы выигрываем?
Далее.
Использование фреймворков оправданно в двух случаях. Нужна мультиплатформенность любой ценой или в штете отсутсвуют достаточно подготовленные программеры. Какую из задач фреймворку будут решать в этом примере?
вопрос, чего сапа индексирует в таком объеме, что нужен для этого сервак?
Теперь о приславутой связке PHP+MySQL. То, что MySQL создавался как "любительское" решение для небольших баз, дело понятное. Это видно и по структуре баз да и по механизму. Это задача не для него. Теперь пхп.
ПХП это порождение желания решить две задачи одновременно. Создать механизм ASP для Апача + потеснить Перл, немного его изменив, переделав, усовершенствовав. Отказаться от модульного построения библиотек, такой механизм проще для освоения новичками. Еще ему прикрутили сессии, которые сам Аппач очень плохо реализует. Механизм(объект), аналогичный Appolication так и не смогли толком реализовать. Начала мешать изолированность памяти.
Механизм ASP (как технологии), значительно медленнее чем CGI. Конечно, PHP скрипты работают через серверный интерфейс CGI, но, по сути являются ASP. Потери в скорости очевидны.
Безусловно, появление пхп привлекло очень много людей к вебпрограммированию, т.к. он стал куда проще, но не стоит забывать, что это далеко не едиственно решение для любой задачи, и для того, чтобы понимать что и для чего стоит использовать, нужно знать как можно больше.
от 1 до 30 К в сутки на разных сайтах. Естественно Перл. На серваке около 70 сайтов. Сервак свой.
безусловно. Это удобней и быстрее.
ошибаетесь. Т.е. Вы считаете что если расширение PNG/GIF (как у большиства счетчиков), то на отдающем серваке и правда лежат такие статичиские картинки?
Вернее так утверждают только те, кто не сталкивался с "шалостями" любителей поломать сайты. Именно поэтому еще и инфа о сервере маскируется, вернее о его истинно ПО.
и Вы делаете однозначное заключени...
Конечно, если люди линивы, то именно пхп и юзали... хотя, возможно, клиентская часть на нем и написана
я для своих сайтов (пользую только самописанные системы управления), использую урлы с расширением или cgi или asp. Так проще бороться с пионерами..
Вебб-часть , скорее перл, он более гибкий и удобный чем пхп. (яша и его некоторые боты работают именно на перл). Безусловно, никаких UTF. Лучше всего KOI8R, но пойдет и win1251.
БД - что более серьезное чем MySQL, но там больше дело вку. База ненастольок большая. Т.к. сейчас дисковое простанство стоит копейки, значит можно увеличивать объем базы для увеличения скорости.
Часть сервиса, которая работает по таймеру (реиндексация, пересчет, и.д.), вобщем вся асинхронная..., или си или перл. Конечно колокейт. Я бы делал 2 сервака. Один для юзеров, воторой - трансятор рекламы. И надежней и меньше вероятность падения всего сразу.
