Veseloff

Я уже не помню — сто лет не видел денвер, но вроде бы z:/home/localhost/www — как-то так

Не, ну количество и размер картинок и прочих цсс тоже на сервер влияет будь здоров

А документация денвера не подсказывает?

Вот тут как получается. Допустим, разработка при помощи фреймворков, готовых CMS всегда ускоряет процесс собственно разработки, но будет медленнее, чем просто набор скриптов, написанных под задачу. У меня есть несколько проектов, которые работают и я надеюсь, что они когда-нибудь станут популярными, а, значит, они будут нагружать оборудование. Суть в том, что они все написаны за несколько дней, используя мой самописный «движок», который я использую обычно в работе и нормально работают. В среднем всё отрабатывается за 0,03 сек, что сейчас легко переносимо, а, если попрёт, то будет много. Для простоты расчётов допустим, что всего 10 проектов и каждый из них делался по 10 дней. Итого 100 дней. Чтобы каждый из проектов максимально оптимизировать потребуется ещё 300 дней, никак не меньше, то есть 30 на один проект. Маловероятно, что «выстрелят» все 10 — максимум 2. Итого надо будет потратить не 400 дней, а 160, что, конечно же лучше. Так же я работаю и с клиентами. Я сразу предупреждаю о скорости, цене разработки и о том, что есть предел по посещаемости. То есть, например, я говорю, что можно заплатить 1000, я всё сделаю за 10 дней, но сайт не выдержит больше 10 000 посетителей в сутки. Могу всё сделать за 4000 за 40 дней, надо будет ещё потратиться на оборудование, но будет спокойно держать 300 000. Так вот всегда говорят, что заплатят 1000, а потом, когда станет посетителей больше 10 000, так обратятся ещё раз. И всё правильно делают — почти никто не достигает лимита

У меня самый нормальный хостинг — один сервер дома и ещё один в офисе. Аптайм нормальный. Полная свобода действий и, что немаловажно, это бесплатно, ибо я так и сяк буду за интернет дома платить, а тут ещё и сервер воткнул, чтобы не простаивал канал.

Что я думаю обо всём этом. В принципе, ничего плохого в этом нет — качественный продукт это всегда хорошо. Например, есть сайт у которого 3 css файла подключаются, jquery, highslide, ещё что-нибудь — это всё отлично работает и загружается за секунду. Но это происходит до поры — когда количество просмотров начинает переваливать за 100к в сутки, то вот тут встаёт вопрос, что неплохо было бы js совместить в один файл, с css так же поступить, а ещё бы и серверный код оптимизировать. Каждая миллисекунда на счету. Почему оптимизация бывает преждевременной? Ну потому, что мало у кого количество посетителей переваливает хотя бы за 5к, так что тратить время на оптимизацию того, что можно и не оптимизировать — пустая трата времени. Оптимизация «веса» картинок — важная вещь на любом этапе, так как даже на ненагруженном сайте 2МБ информации будет грузиться долго. А вот оптимизация количества файлов и кода — это надо откладывать на потом.

Увы. Мне это как-то не нужно, поэтому ничего про это не знаю.

Надо, скажем так, чувствовать ту грань между количеством файлов и длиной кода. Дофига обращений к серверу — конечно же плохо. Что вам мешает, например, совместить все картинки в одном-двух файлах? Что вам мешает совместить всесь js в одном файле? Все стили? Ну да, для хаков сделаем ещё один файл, который будет загружаться только тогда, когда это необходимо. В итоге иметь будем следующую схему: 1. Один файл со стилями 2. Один файл с js 3. Один файл с картинками (можно больше — в зависимости от размеров, тут ещё надо про оптимизацию изображений кое-что знать) Итого три или чуть больше. Но никак не 72. А ну и ещё вот такой момент. Чем короче PHP (или любой другой серверный код), тем быстрее он будет отрабатываться. Недавно видел отличное решение — серверный скрипт (в данном случае Perl) всё считал, что нужно, преобразовывал в json и выдавал только его. Всё построение страницы было сделано на статике и js. То есть примерно такая схема. 1. Пользователь запрашивает страницу 2. Nginx, который стоит на фронте выплёвывает статичный HTML — один из небольшого набора шаблонов, хранимые статикой. 3. Внутри этого шаблона идёт обращение в файл типа some.js, который создаётся при помощи серверных скриптов. 4. Ещё один файл на js занимается шаблонизацией, то есть построением данных из того, что пришло в some.js Если шаблоны страницы выдаются серверными скриптами, то это удлиняет скрипт, отчего он медленнее работает и больше тратится трафика, так как js-шаблонизатор после первой загрузки не отдаётся вообще, ибо 304.

Это что за адская жесть? Это не сработает — выдаст фатал еррор. Или вы присваиваете переменной $_REQUEST какое-то строковое значение? Допустим, что вы опечатались и на самом деле так $_REQUEST['page']. А что будет, если сделать ?page=index А если файла такого не существует?

Насчёт доктайпа. Я люблю сравнивать всё с автомобилями. Ну вот, например, сделали вы автомобиль с двигателем на крыше — и чего? Он ездит, да. Но вот двигатель-то на крыше! Мне кажется, что это несколько смутит потенциальных покупателей. Что касается «своих законов вордпресса», то это не говорит о том, что вордпресс плохой (хотя это так), а о ваше неспособности в нём разобраться. Насчёт уменьшения числа запросов к серверу. А у вас он под дичайшей нагрузкой? Если нет, то вы делаете одну из главных ошибок разаработчиков — преждевременная оптимизация. Да вообще смешно говорить о каком-то снижении нагрузки, когда у вас вордпресс. Ну и, раз уж про оптимизацию заговорили, то доля IE, под которые делаются хаки весьма невелика и, значит, куски кода, которые работают только для IE нужны не так часто. Удлиннение кода даёт нехилый прирост нагрузки на PHP, ну и, конечно же, трафик растёт. Nginx достаточно быстро выплюнет файл или отдаст 304, а PHP надо больше времени, чтобы «пропердеться», выдать всё в апач и апач уже будет выдавать этот длинный текст. Статика всегда работает быстрее динамики, если всё правильно сделано. Так что или разбирайтесь с вордпрессом или пользуйтесь чем-то ещё.

Так, ну давайте по порядку. Сначала я вообще просто обалдел, если честно. Было плохо, а стало интересно. Правда, когда я понял, что всё не своё, то огорчился. Ну, с другой стороны, лучше хорошее и не своё, чем своё, но плохое. Не знаю как там с правообладателем, но, если с этим проблем нет, то это, конечно, не так уж и плохо. 2,2 МБ — много. У меня интернеты быстры и я не заметил, что много. Но кто-то, вероятно, заметит. Закладки какие-то непонятные — вообще не к месту. Облако тегов тоже — зачем оно? Доктайп должен стоять первой строкой, а не третьей. Стили и JS внутри кода — отвратительно. Короче, ещё работать и работать.

Так, ну я тут накидал по-быстрому. Не факт, что 100% правильно работает, но логика, мне кажется должна быть какая-то такая. preg_replace('~(?(?=<a href=\".*?\">.*?</a>))<a href=\"(.*?)\">(.*?)</a>|(http:\/\/[a-z]+[-\da-z\.]*\.[a-z]{2,6})~i', '<a href="\\1\\3">\\1\\3</a>', $s); Что следует исправить: 1. Вернуть все параметры, которые есть в исходном теге a. 2. Выключить жадность (не помню модификатор — «U» вроде бы, но лень гуглить) на всю регулярку и заменить «*?» на «*». Будут вопросы — задавайте. (?<!<a[\s\S]+?href=") Вроде бы и не должна работать, поскольку отрицание вперёд (или как это правильно называется) не работает с переменными длинами. Это, конечно, досадно.

Ну защитить вёрстку, как и дизайн, вообще проблематично. Вёрстку можно немного обфусцировать, наверное, но её так же легко можно вернуть к нормальному виду, да и вообще можно оставлять как есть, если всё работает, а изменений не предвидится. С дизайном вообще не знаю как поступать — единственное, что приходит на ум — делать ватермарки, но и тут часто бывает так, что заказывается работа дизайнера, скажем за 3000$, который рисует макет, делает на него ватермарки, ему не платятся деньги, а макет перерисовывает фотошопщик за 300$. У иллюстраторов, конечно, попроще — перерисовать будет стоить столько же, сколько и нарисовать с нуля. Я говорю только о серверных скриптах. Ну и самое слабое место разработки топикстартера, конечно же, в том, что заказчик всё равно должен заплатить только после окончания работы. Если он решил не платить, то он копирует все скрипты себе с сервера, объявляет о нежелании платить и хоть заудаляйся их на исходном сервере, хоть все базы снеси — у заказчика есть копия и за 30$ найдётся человек, который всё это хозяйство вычистит из скриптов.

А смысл? Заказчик кидает разработчика, чтобы не заплатить денег за готовую работу. Разработчику же нет смысла не отдавать уже готовый продукт в случае, если он его сделал и ему за это заплатили деньги. Набор скриптов — вещь нематериальная, поэтому его нельзя, например, сравнивать с товаром материальным, кгода, например, заказал в интернет-магазине ноутбук, заплатил денег, а тебе его не дали — у продавца остаётся и ноутбук и деньги. В случае со скриптами они даже при передаче остаются у разработчика. Разработчик ничего не теряет, отдав скрипты, которые он написал. Как-то так, наверное...

На самом деле решается всё ещё проще — до получения денег сайт лежит на своём сервере, к которому у клиента, естественно, нет никакого доступа.

Это ты зря. Не то, чтобы дизайнер должен их хорошо знать, но иметь полное представление о том, как это верстается крайне необходимо. Бывает, такие макеты рисуют, что вообще непонятно как верстать. Веб-дизайнер обязан представлять во что обойдётся вёрстка макета и правильно выбирать между сказочной красотой и стоимостью вёрстки. Ну и, плюс ко всему, надо, чтобы он понимал как надо нарезать макет, чтобы его было легко сверстать. Это важно и экономит очень много времени.

Проблема в том, что так писать нельзя. Писать надо типа так: onmouseover="this.style.border='...'"

Да, по-моему, различие основное в том, что в нерабочем примере есть кавычки, а в рабочем их нет. Или я ошибаюсь? Помнится просто какой-то затык с кавычками в селекторах.

Кто пишет?

А почему тогда в «Обсуждении работ»? Нет уж, пусть оценивают.

1. Это тема для ветки СУБД. 2. Структуру таблицы в студию

Да обсуждать нечего особо — всё одной картинкой сделано. Не увидел открывающего тега html. Скрипты и стили лучше выносить в отдельные файлы. При таком доктайпе надо закрывать одиночные теги и писать все сущности маленькими буквами. Таблицы используются для нетабличных данных. Короче, ничего хорошего.

Я тут ещё раз код посмотрел и увидел, что id не «link», а «dellink». Соответственно, надо и удалять $('#dellink').remove();

Если есть id="link", то правильно делать так $('#link').remove();

В настройках сервера. Ну или из скрипта заголовки отсылайте с нужной кодировкой. Но лучше всё-таки в настройках сервера.