С комментариями не совсем так. Органичить вложенность не потому, что 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 - новости рынка
Мы используем частично позаимствованные методики из ХР-программирования - владение кодом вдвоем. То есть:
1. Дизайнер режет макет вместе с верстальщиком. За эти 3-4 часа они успевают друг с другом обсудить детали, особенности.
2. Верстальщик первый день работает с программером вместе - навешивает шаблоны на типовые модули (типа, новостей, текста, поиска и пр.)
На первый взгляд - люди тратят некоторое время впустую... Но, как показывает практика, совместное сидение за монитором 2-х людей помогает не отвлекаться, лучше выискиваются ошибки, и есть преемственность действий. Но обо всем этом можно узнать из методики Экстремального Программирования, например, http://www.exprogramming.ru/
Дизайнеры и спецы по юзабилити это эстеты. Как есть отдельная каста программеров и админов со своими устоями, шутками и пр., так и у людей "прекрасного" есть свои заморочки. Дело, ИМХО, не совсем в деньгах - всяких дизайн-проектов в сети предостаточно. Просто довольно сложно подружить эти две касты. Ну, работать совместно за деньги они согласны, но все же они разные...
Помню, как в отдел разработки прибегает менеджер и кричит: "Кто губкой для мытья посуды вытирал ботинки?" На что дизайнер сокрушенно отвечает - "Да посмотрите на программеров - из них никто ботинки вообще не чистит!" Мы все ржали.
Дак вроде и раньше, в детстве, как помню, родители не играли со мной в казаки-разбойники. Но опасная тенденция есть. Уж больно много вьюноши проводят времени за компом.
На 80% того, что мы читаем и видим с экранов - это PR. Да, Майкрософт сказала. Но так же были неприятные случаи, когда была акция легализации (типа, пользовался пиратским софтом, купил лицензию - чист и свободен). Все бы ничего, но были случаи (и их можно найти в и-нете) когда после заявки на приобретение лицензии у MS, в конторы вламывались менты (какое совпадение). Со всеми вытекающими. И это притом, что у нас в центре Москвы есть Горбушка. Сами понимаете - тут сложный клубок. Но если с самого начала были бы какие-нибудь Suse, Debian и иже с ними - таких проблем не было бы.
Поймите, я сейчас могу купить себе программы, что мне нужны - но есть огромное кол-во пользователей, которые не могут купить все программы - они просто не знают о существовании других ОС.
Ну и тут есть подвижки. Например, в новой школе №2030 поставили Mac OS X - ну и отлично. Да, школа новая, видимо, с поддержкой Правительства Москвы... Есть деньги - почему бы Мас не поставить. Давайте сами, кто как может помогать процессу. Не надо никого переубеждать - просто расскажите об альтернативах.
Плюс, если автор смог бы выбрать 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 - новости рынка
Спасибо.
1. Дизайнер режет макет вместе с верстальщиком. За эти 3-4 часа они успевают друг с другом обсудить детали, особенности.
2. Верстальщик первый день работает с программером вместе - навешивает шаблоны на типовые модули (типа, новостей, текста, поиска и пр.)
На первый взгляд - люди тратят некоторое время впустую... Но, как показывает практика, совместное сидение за монитором 2-х людей помогает не отвлекаться, лучше выискиваются ошибки, и есть преемственность действий. Но обо всем этом можно узнать из методики Экстремального Программирования, например, http://www.exprogramming.ru/
Помню, как в отдел разработки прибегает менеджер и кричит: "Кто губкой для мытья посуды вытирал ботинки?" На что дизайнер сокрушенно отвечает - "Да посмотрите на программеров - из них никто ботинки вообще не чистит!" Мы все ржали.
Поймите, я сейчас могу купить себе программы, что мне нужны - но есть огромное кол-во пользователей, которые не могут купить все программы - они просто не знают о существовании других ОС.
Ну и тут есть подвижки. Например, в новой школе №2030 поставили Mac OS X - ну и отлично. Да, школа новая, видимо, с поддержкой Правительства Москвы... Есть деньги - почему бы Мас не поставить. Давайте сами, кто как может помогать процессу. Не надо никого переубеждать - просто расскажите об альтернативах.