Я тоже всегда сравниваю сайты с авто. Ещё можно добавить про стоимость доделок по сайту (опции для машины) и дописывание новой функциональности (ремонт или тюнинг). Спасибо за статью!
С комментариями не совсем так. Органичить вложенность не потому, что textarea маленький, а чтобы постоянной перебранки не было.
Плюс, если автор смог бы выбрать 5-7 толковых комментариев и прицепить их прямо после статьи - было бы удобно. Тогда повышается фильтрация от "шума" и ценность статьи возрастает.
Насущная проблема. Тут, можно вот еще о чем подумать:
1. У многих топиков разное время жизни.
- новость - 2-5 дней
- статья - до 1 года
- фундаментальный материал (как wiki) несколько лет.
Может как-то учитывать это?
2. Система комментариев. В личном блоге приятно почитать "Спасибо за материал". При большом кол-ве комментариев это начинает мешать. Плюс ко всему система с древовидными комментариями затрудняет чтение - мысли разбегаются, начинаются перепалки. Может ограничивать вложенность?
Я согласен, что тонкости хостинга (как и многие другие тонкости) стоит указыать в приложениях или ТЗ. Может, в скобках стоит указывать - что куда ссылается - для общего понимания.
П. 3.5 Стоит оговорить, на кокой хостинг. Все ли там установленно. А то как то нам дали IP адрес для SSH, логин и пароль. А все остальное - устанавливайте сами. Пришлось оговаривать, что это будет дополнительно работой с привлечением квалифицированного системного администратора.
А мы стараемся в разговоре с Заказчиком сразу расставить все точки над "ё".
1. Показать примеры готовых работ. Сделать упор на общий стиль и концепцию - нравится - продолжаем работать - нет - значит надо искать других Исполнителей. Иначе себе дороже работать.
2. Составление плана работ и среднего по объёму ТЗ. Все равно на 100% редко получается все реализовавать. Мы просто закладываем в смету дополнительные 20% работы.
3. Очень важно определить роли. Заказчик отвечает на вопрос "Что?" - дает исходное задание, в чём идея, задача, что нравится и т.д. Исполнитель отвечает на вопрос "Как?". И это очень важно сразу определить. Потому как если Заказчик начинает говорить, как надо делать дизайн - он занимается не своей работой - его работа - уменьшать риски компании и повышать прибыльность. Если есть несогласие - см. пункт №1.
4. Поэтапность работ. Показали макеты. Приняли? Получили подтверждение по e-mail-у? Значит Заказчик принял на себя обязательства по данному вопросу. Если потом возникают проблемы - отправляем к письму за нужную дату - "Сами утверждали?" - отвечайте. Или Заказчик (его представитель) некомпитентен.
5. На все вопросы "Ну, это ведь несложно сделать" - отвечаем, что и в работе президента банка тоже ничего сложного, однако, он получает свою зарплату. Если вы сами /переверстаете макет /настроите UNIX сервер /допишите программный модуль/ - мы будем на против. Но наша работа сверх ТЗ стоит Х рублей в час.
И если спокойно проговорить с Заказчиком основные моменты - можно выяснить - найдется у вас общий язык, или нет. Просто спокойно по-человечески поговорить. Обычно, люди (если к ним нормально относиться) довольно вменяемы.
З.Ы. Стоит брать 30% невозвращаемой предоплаты - так мне один Заказчик говорил - за что ему и благодарен. Спасибо, что дочитали :)
Да - во все случаях Apache. Проблема в том, что не всегда статика возможна. Для таких случаев можно использовать nginx как прокси сервер для апаса к http запросов к скриптам. А картинки и статику пусть сам nginx выдает. Это ускоряет работу сервера. Проверено.
Полезная статья. Но это только частный случай внимания разработчиков к производительности. Сам все собираюсь написать более общий материал. Посмотрел свою статистику, что получается для локального ноута CoreDuo 2.0 c Apache 1.3. Все цифры - кол-во ответов в секунду.
Еще один трюк. Я при создании кеша титульной страницы создаю index.html - и говорю .htaccess первым выдавать его. А как известно, на титул приходится большая часть запросов. Так же можно сделать для списка последних новостей, первой страницы каталога и прочего.
1. Имя класса/модуля ведь совпадает с именем таблицы, так? А если база данных у меня одна (такой часто встречается у провайдеров), но есть 2 сайта. На них есть модуль news. Но у каждого сайта должно быть хранение своих данных. А таблица называется едино.
В своих наработках я указывал префик для таблицы. Например, r1_ для сайта №1 (r1_news), и r2_ для другого. Как это в фреймворке порешать изящно?
Полезная информация. Спасибо! Сам выбираю фреймворк. Никак не могу остановиться на конкретном варианте. Symfony - очень тормозной, CodeIgniter - быстр, но прост. Cake в этом смысле некая золотая середина.
Меня волнуют 2 момента, подскажите, пожалуйста, кто знает:
1. Как делать для таблиц префиксы, например r4_news - чтобы можно было в одну базу поместить несколько проектов.
2. Как на фрейморке толково реализовать вложеную структуру сайта. Например,
domain.ru/about - текст
domain.ru/about/mission - текст
domain.ru/about/corpnews - новости компании
domain.ru/about/news - новости рынка
http://wiki.rubyonrails.org/rails/pages/…
Догадываюсь, что есть достаточное кол-во людей, которые переходят с пхп на питон или руби. Основные преимущества сто раз оговорены. Но что беспокоит:
1. Пока много хостинга на пхп. И многие заказчики не будут переезжать на другой, тем паче на VPS.
2. Из п.1 вытекает, что вроде полезно некоторые проекты делать на пхп фреймворке, но уж больно тяжко сразу 2 продукта изучать.
3. Бескомпромисный вариант. Для пхп использовать старый движок (тот, с которым работал), потихоньку учить питон и при возможности писать на нем.
Кто как поступает в таких случаях?
Простые ответы на 7 популярных вопросов по сайтостроительству.
Плюс, если автор смог бы выбрать 5-7 толковых комментариев и прицепить их прямо после статьи - было бы удобно. Тогда повышается фильтрация от "шума" и ценность статьи возрастает.
1. У многих топиков разное время жизни.
- новость - 2-5 дней
- статья - до 1 года
- фундаментальный материал (как wiki) несколько лет.
Может как-то учитывать это?
2. Система комментариев. В личном блоге приятно почитать "Спасибо за материал". При большом кол-ве комментариев это начинает мешать. Плюс ко всему система с древовидными комментариями затрудняет чтение - мысли разбегаются, начинаются перепалки. Может ограничивать вложенность?
1. Показать примеры готовых работ. Сделать упор на общий стиль и концепцию - нравится - продолжаем работать - нет - значит надо искать других Исполнителей. Иначе себе дороже работать.
2. Составление плана работ и среднего по объёму ТЗ. Все равно на 100% редко получается все реализовавать. Мы просто закладываем в смету дополнительные 20% работы.
3. Очень важно определить роли. Заказчик отвечает на вопрос "Что?" - дает исходное задание, в чём идея, задача, что нравится и т.д. Исполнитель отвечает на вопрос "Как?". И это очень важно сразу определить. Потому как если Заказчик начинает говорить, как надо делать дизайн - он занимается не своей работой - его работа - уменьшать риски компании и повышать прибыльность. Если есть несогласие - см. пункт №1.
4. Поэтапность работ. Показали макеты. Приняли? Получили подтверждение по e-mail-у? Значит Заказчик принял на себя обязательства по данному вопросу. Если потом возникают проблемы - отправляем к письму за нужную дату - "Сами утверждали?" - отвечайте. Или Заказчик (его представитель) некомпитентен.
5. На все вопросы "Ну, это ведь несложно сделать" - отвечаем, что и в работе президента банка тоже ничего сложного, однако, он получает свою зарплату. Если вы сами /переверстаете макет /настроите UNIX сервер /допишите программный модуль/ - мы будем на против. Но наша работа сверх ТЗ стоит Х рублей в час.
И если спокойно проговорить с Заказчиком основные моменты - можно выяснить - найдется у вас общий язык, или нет. Просто спокойно по-человечески поговорить. Обычно, люди (если к ним нормально относиться) довольно вменяемы.
З.Ы. Стоит брать 30% невозвращаемой предоплаты - так мне один Заказчик говорил - за что ему и благодарен. Спасибо, что дочитали :)
1. Быстро
2. Качественно
3. Недорого
Вы можете выбрать только 2 пункта.
1. Чистый html - 1350
2. SSI (включая 6 файлов) - 890
3. php (php_mod) echo - 45
4. php (cgi) echo - 24
5. php (cgi) + PEAR_Lite_Cache - 21
6. php (cgi) no cache (средняя страница сайта) - 4
Еще один трюк. Я при создании кеша титульной страницы создаю index.html - и говорю .htaccess первым выдавать его. А как известно, на титул приходится большая часть запросов. Так же можно сделать для списка последних новостей, первой страницы каталога и прочего.
В своих наработках я указывал префик для таблицы. Например, r1_ для сайта №1 (r1_news), и r2_ для другого. Как это в фреймворке порешать изящно?
Меня волнуют 2 момента, подскажите, пожалуйста, кто знает:
1. Как делать для таблиц префиксы, например r4_news - чтобы можно было в одну базу поместить несколько проектов.
2. Как на фрейморке толково реализовать вложеную структуру сайта. Например,
domain.ru/about - текст
domain.ru/about/mission - текст
domain.ru/about/corpnews - новости компании
domain.ru/about/news - новости рынка
Спасибо.