Нормальные современные CMS к дизайну сайта не привязаны никак, то есть дизайн полностью настраивается как набор шаблонов на HTML (может быть завернут в XML/XSLT или как-то еще - сути не меняет) верстальщиком. Что заверстаете - то и будет на сайте.
Да не за что :).
Чтобы точно ответить - нужно понимать внутреннее устройство Postgres (или правильно Postgre?). Мне кажется, что объем базы на скорость выборки из нее влиять не должен, т.к. доступ к файлам с данными производится в произвольном режиме, по индексам (если они есть - проверьте!). То есть если нужна запись в середине одногигового файла - она возьмется с той же скоростью что и из 10 килобайтного. Другое дело, что обслуживать такую БД сложнее, при записи в нее могут быть тормоза (если применен какой-нибудь кластерный индекс или еще что-то подобное) и с архитектурной точки зрения совершенно неверно.
Плохо то, что картинка каждый раз будет выдираться из БД в память и оттуда сливаться навстречу радостным пользователям. Это большой расход памяти, приличное время выдирания картинки из blob, неизвестная эффективность при одновременном запросе одной картинки 100 пользователями, лишняя процессорная загрузка для вывода бинарных данных наружу и так далее. Поэтому конечно в любом случае картинки нужно выносить на уровень файловой системы, а в базе хранить только ссылки на них. Опять же при такой схеме за выдачу картинок наружу будет отвечать уже сам Апач (на форуме где-то читал что на очень нагруженных проектах под выдачу картинок вообще отдельный веб-сервер ставят, типа Nginx, кажется).
Можно 100% гарантировать что скорость работы увеличится, но насколько - зависит от остальной мишуры и особенностей устройства и настройки СУБД. Может выигрыш будет всего 3-5% (по скорости), а может в разы. Но учитывая, что не скоростью единой - нужно все ресурсы считать до кучи - то я бы обязательно рекомендовал от такой схемы уйти.
Скорее всего чистое время генерации страницы Вам не нужно (посчитать его можно именно расставив по коду операторы вывода куда-нибудь текущего времени с высокой точностью). Скорее всего Вам нужно понять насколько быстро в целом сайт будет любые страницы (или определенную страницу) отдавать наружу. Проверка эта в общем случае называется "нагрузочное тестирование". В простейшем случае сводится к запуску нескольких клиентов для обращений к странице в цикле и логировании результатов. Можно написать простой скрипт, эмулирующий работу одного пользователя, самому (например сделать bat файл для запуска утилиты wget в цикле), или воспользоваться, бесплатными (или платными) промышленными средствами. Например, можно взять Microsoft Web Application Stress Tool. Простая в обращении программа, хелп правда нужно читать обязательно чтобы понять теорию тестирования (3 абзаца).
Это если в лоб. Если знать архитектуру системы, то наверняка сравнение можно провести и более качественно, зная узкие места. Из общих соображений мне кажется что PHP или Ruby будет совершенно все равно, т.к. оба языка скриптовые. То есть интерпретатору нужно время на открытие файла с кодом, парсинг его и интерпретацию всех инструкций при каждом запросе к скрипту. А это примерно одинаковое время для Perl, PHP, Ruby, ASP и пр. Для компилируемых языков (ява, технологии дотнет и пр.) естественно время работы каждого скрипта значительно меньше.
Если у веб-сервера есть средства для кэширования приложений (все что mod_... для Апача или др.) то приложение в целом будет работать быстрее (не нужно тратить время на загрузку файла в память и некоторые другие частые операции), но от самого языка - практически никак не зависит. Файловые операции и проч. стрингоориентированная ботва во всех языках по скорости примерно одинакова, если глубоко в регулярные выражения не лезть.
Также из общих изображений - для веб-приложений с приличного объема базой данных язык также не будет играть решающего значения, поскольку все время будет отъедаться на всякие select-update на уровне СУБД.
Прикольно обрабатывают URL люди. Адрес вот такого вида http://electrohouse.ru/voprosy.\'ivp приводит к зацикливанию.
Если нужно убрать редирект, то можно написать проксирующий скрипт, который будет обращаться к нужной странице на локальном же сайте, скачивать её и выдавать в ответ. Для всех страниц это тоже решается, просто по сути городишь надстройку над CMSом.
Хотя я не совсем понял что значит "ВИРТУАЛЬНУЮ СТРАНИЦУ НЕЛЬЗЯ ПРОПИСАТЬ В IIS В КАЧЕСТВЕ ДОКУМЕНТА ПО УМОЛЧАНИЮ"? Можно прописать URL /default.ivp в обработчик ошибки 404. Как я понимаю, разработчик(и) не решил вопрос как обрабатывать 404 для всех остальных страниц, поскольку назначить свой обработчик 404 на каждый раздел отдельно без программирования нельзя. В любом случае вариант №2 - обработчик default.ivp записывается в 404 для всего сайта, а уже внутри него программируется обработка URL и переход на соответствующий .ivp файл.
Первый способ можно сделать на любом языке (Perl, PHP, ASP тот же) который установлен на сервере. Второй - по сути модификация CMS, нужно будет смотреть что там за ivp такой и на нем писать.
Это все понятно и очевидно, с моей личной точки зрения и исходя из опыта все что Вы перечислили на доход компании влияет меньше, чем если компания просто продает проекты не по 5 а по 10. Идея моя была именно такой: умение продать "за дорого" более прибыльно, чем умение заставлять персонал работать на износ, изобретать суперские программерские решения и рисовать супер дизайн.
Хотя мы, естественно, делаем и то и другое.
Да очень просто. Идете работать в нормальную веб-студию младшим верстальщиком. Если через пару лет дорастете до руководителя отдела или направления - такие вопросы для Вас уже будут неактуальны. А если нет - значит не судьба :).
Да не готов. А я обязан это делать? К моим высказываниям в данном треде Ваш вопрос не имеет никакого отношения, я говорил о других вещах. Вы сами ничего подобного не рассказываете. Было бы странно полагать, что я буду открывать какие-то подобные вещи на этом форуме. Скажите мне - какой в этом смысл?
Вы хотите меня в чем-то упрекнуть? Я в чем-то неправ высказывая свое мнение о причинах демпинга на рынке? Или Вы хотите взять меня на слабо? Не совсем понимаю зачем.
Поскольку все свои мысли по теме я уже высказал, с достоинством удаляюсь :). Спасибо за внимание.
Каширин, (извините, что по фамилии, но у Вас ник такой) - сайт для телефонов за 200 действительно должен отличаться от сайта для телефонов за 800. В первую очередь креативным дизайном, подачей материала. Но юзабилити, то есть удобство пользования у них будет примерно одинаковым. В первую очередь потому, что лично я не вижу никакой принципиальной разницы между человеком, который может купить телефон "за дорого" и "за дешево". Рук, ног, глаз у них одинаковое количество. Мышь у них устроена примерно одинаково. "В среднем", если это выражение вообще имеет право на жизнь, у этих людей и поведение и привычки пользования браузером и сайтами тоже будут одинаковыми. Вы же не станете утверждать, что винда для богатых и винда для бедных чем то отличается по интерфейсу? Да, она имеет специальный интерфейс для инвалидов. Вот это - действительно другая целевая аудитория!
Junior, если честно, ваш отзыв в репутации единственный отрицательный в этом треде. Я понимаю, что Вы можете быть несогласны со мной, но тогда продолжайте спор аргументированно, обвинять других в незнании чего-либо проще всего. Создается впечатление, что Вы обиделись. Если это так - извините, я обидеть никого не хотел. Тем не менее, ждем вашего эксперта с рассказом. Хотя я и сам приложил руки ко многим солидным и известным проектам именно в качестве проектировщика интерфейсов, я признаю что мой опыт не может быть единственно правильным. И поэтому, я с удовольствием послушаю других умных людей и если будет возможность - поучусь у них.
Чего и Вам всячески желаю.
Мне кажется рассказывать публично о деталях ведения своего бизнеса достаточно глупо по очевидным причинам.
Извините, но это уже какие-то препирательства, флэйм в чистом виде. Поэтому по пунктам отвечать не буду. Только один комментарий - юзабилити промо-сайтов для сотовых телефонов за 800 долларов ничем не отличается от юзабилити промо-сайтов за 200 долларов по многим причинам. В том числе и по той, что телефоны за 800 баксов у нас в последнее время покупают даже школьники, у которых денег "на пожрать нормально" нет. Такая у нас специфика "целевой аудитории" - последние деньги тратятся на крутые машины когда у человека еще даже квартиры нет.
И вообще, интернет эргономика от целевой аудитории практически никак не зависит. Только узкоспециализированные ресурсы, например веб-интерфейсные эмуляторы терминалов по бронированию авиа и жд билетов, можно и нужно проектировать под какой-то конкретный профиль пользователя. В расчете на то, что он "в теме" намного больше, чем случайный прохожий и объяснять ему досконально ничего не нужно. Для обычных рядовых сайтов, особенно для ориентированных на продажу чего-либо, законы построения интерфейсов одинаковы. Это очевидно.
Касательно Вашей подписи - по-прежнему не понимаю почему не написать свой род занятий, профессию по-русски? Вот лично я не понимаю что Вы там написали. Information System Architecture - это что? Вы хотите сказать что "занимаетесь архитектурой"? Ну и пишите тогда правильно - System Architect, системный архитектор. В конце концов, в гугл зашейте то, что Вы пишете и посмотрите - если такого словосочетания нет, то и незачем его изобретать. Хотя более правильно просто выучить английский. Или понять чем же Вы занимаетесь и как это называется на русском языке.
