Когда вы открываете свой проект вы начинаете писать о нем везде, в том числе и на хабре.

Сервисы статистики типа Google Analytics дадут вам общую оценку трафика, а именно сколько посетителей пришло с какого ресурса. Можно настроить цели(goals) и отследить регистрации или покупки, но этого часто бывает недостаточно.

А что если вам нужна статистика о том откуда идут более активные пользователи или пользователи которые создали больше всего тем на форуме за какой-то промежуток времени, или сделали больше всего покупок в вашем интернет магазине. Вариантов может быть много и такие данные сервисы аналитики уже дать нет смогут.

Привет, %username%
Тут я хочу рассказать о том, как я настраивал кеширование на одном сервере, точнее VDS. Характеристики сервера: 2000MHz, 2GB RAM, 80Gb HDD, технология виртуализации — OpenVZ.
Было решено использовать Nginx версии 0.7.64. На сервере находилось около 200 сайтов. И несколько высоко нагруженных проектов. Вот эти самые проекты и давали ощутимые тормоза и нагрузку на сервер. Мы будем рассматривать DLE в этом примере.

К уже написанному на хабре топику "Мелочи решают все".

Прочитал топик. Согласен со многим написанным там. Но… Я занимаюсь интернет-магазинами давно, и с более или менее постоянной занятостью. Если конечно мне в жизни больше нечем заняться, хотя даже в подобные моменты я занимаюсь интернет-магазинами. Речь в посте пойдет о том как заработать больше на обратной связи с заказчиком, клиентом… ээ «customer» :) И так дальше под катом. Кстати, извините за большое количество текста… но по другому в письменном виде не получается.

Все началось с этой темы на форуме, когда многие на полном серьезе стали рассуждать, мол, nginx совсем не быстрее Apache, и даже перевод документации с официального сайта был неубедителен. Как известно, нет ничего более приятного, чем провести тестирование и показать график для привлечения внимания. Вот например график по обще нагрузке на сервер, попробуйте угадать где тут этап тестирования Nginx, а где — Apache.

Ну а перед тем как узнать правильный ответ — немного про сервер и механизм тестирования.
Дабы исключить всякие подозрения на «подкручивание» своих VDS, тест проводился на стороннем сервере, любезно предоставленным мне для теста одним из участников форума вот в такой кнофигурации:
AMD Athlon X2 5600+ 4 GB DDR2 2×400 GB HDD с Linux Debian в минимальной установке. Весь софт устанавливался стандартным образом — через apt-get. И PHP и Apache ставились в минимальном режиме.
Для объекта тестирования я поставил очень легкий блог Moscquito, который работает без MySQL, написав туда пару постов и камменты.

Часть 1. Вступление.
Часть 2. Сбор данных.
Часть 3. Базовые метрики.
Часть 4. От статистики к аналитике
Часть 5. Разделяй и думай

Достучаться до небес

Самый активный евангелист веб-аналитики Авинаш Кошик в своем блоге уделяет значительное внимание темам, связанным с организацией работы: как убедить начальство в важности аналитики, а главное — как заставить компанию использовать полученные данные. То, что в них содержится важная для бизнеса информация, вроде бы не вызывает сомнений, но даже если руководство согласно с этим, оно обычно игнорирует выводы аналитика. В результате измерения на сайте не сопровождаются анализом изменений показателей, сам сайт делается “на глазок начальника”, а статистика используется только для рисования красивых графиков и общих оценок вроде посещаемости за месяц. Кошик называет это HiPPO, или “МСаВС” — мнение самых высокооплачиваемых сотрудников. С учетом того, что мнение на счет сайта есть у каждого сотрудника, активисту приходится ой как нелегко.

Таких историй на Хабре уже не мало, но, как мне кажется, каждая из них имеет свои нюансы, поэтому все они полезны.
Занимаясь каким-то своим делом, наверное каждый когда-то подходит к черте «отбеливания» своего бизнеса. Что так же в большинстве случаев позволяет подняться на новую ступень. Я говорю о регистрации юридического лица.
Круг клиентов наработан, партнерские отношения налажены, получено достаточно опыта и я решился зарегистрироваться. Кто-то говорил что это очень сложно, кто-то — очень просто. Никто не оказался правым. Сложность — вообще можно оценить только в сравнении.

    Относительно недавно при написании кода очередной модели, передо мной встала задача использования подзапроса (к примеру в join). При этом уже довольно давно я стараюсь как можно меньше писать запросов «в сыром» виде; использую для этого ООП обёртку Zend Framework. Однако, посмотрев в мануале, API, я, к своему удивлению, не нашёл необходимых средств. Но после обращения непосредственно к коду стало ясно, что вложенный запрос можно сделать очень просто!

Доброго времени суток. Многие согласятся с тем, что Zend Framework — это отличный инструмент, который позволяет сильно сократить время разработки проекта (и не только), но всё-равно часто приходится делать copy-paste методов в разных местах (контроллерах, моделях и т. д. ). Одним из таких мест является модель таблицы базы данных.

Zend_Db_Table и так позволяет легко выполнять CRUD операции.

Последнее время на Хабре появляется не так много хороших статей о веб-разработке. Но сейчас не об этом.
Иногда хабралюди делятся интересными идеями, но не раскрывают их сути. И может зря. Потому как в ходе написания статьи (описания) замечаешь то, чего не видел раньше, другие ходы и решения, а читающим проще понять идею и дать дельный совет.
Так несколько дней назад на хабре появилась статья «Электронное табло», в которой автор поделился ссылкой на свою поделку, но из-за недостаточного описания статья получилась из разряда — «посмотри, что я сделал».
Насколько инетересней могла быть статья, если бы автор добавил побольше описания. Потому захотелось показать на примере этой статьи, как можно было бы сделать немного лучше, а заодно и поделиться своей реализацией его задачи.

В одном из моих проектов, которому возможно никогда не суждено родиться (из-за отсутствия времени), понадобилось электронное табло.
Но прилагательное «электронное» носит исключительно образный характер. Нужна была реализация электронного табло в Веб, такого, чтобы никого не убило током и визуально было похоже на своих настоящих электрородителей.

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

Сервис userfly даёт возможность визуально посмотреть, что и как делал пользователь на вашей странице.
Пока все это в разработке и видимо еще много чего нужно сделать, но основу уже можно попробывать

После регистрации userfly генерирует небольшой Яваскрипт, который нужно вставить в header страниц. После этого все передвижения пользователей будут записыватся, а вы вскоре сможете посмотреть, как небольшой видеоролик, что-же делают посетители на вашей странице, что ищут, какие функции используют чаще и т.д.

Речь в статье пойдет о такой, казалось бы изжеваной и изъезженой теме, как валидация веб-документа по одной из DTD-схем, которые в свою очередь определяются с помощью DOCTYPE.

Тема эта нетривиальна; преимущества и недостатки того или иного способа валидации на первый взгляд не всегда являются явными. Поэтому я решил что упомянуть о них еще раз будет не лишним.

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

Как то гуляя в интернете наткнулся на интересную ссылку — Коды мобильных операторов. И очень мне захотелось иметь такую базу локально.
Под катом дамп mysql базы, php код для её использования и скрипт парсер для обновления.

(2008 год, письмо старшего менеджера веб-студии — младшему)
( профи вряд ли найдут что-то новое, молодым будет интересно)
Привет. Вот краткая инструкция, основанная на личном опыте. Так сказать, курс молодого бойца.
наша задача — заработать как можно больше денег, при минимальных телодвижениях.

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.