Сегодня, мы неожиданно получили первый доход, смешной, всего 5 долларов, но радости было много, потому что первый, и потому что неожиданно. Наш первый доход принесла нам реферальная программа AdWords. В пятницу разместили статью для наших пользователей о том, как привлекать клиентов на их сатйы, частью которой была рекомендация использовать контекстную рекламу, и в понедельник получили первые материальные результаты. Пустяк, но это действительно неожиданный и совершенно не запланированный доход для нас, который по нашим прикидкам в будущем сможет стабильно приносить деньги, сколько - поживем увидим. Главное что это типичная all win ситуация, так как контекст для наших клиентов (малого и среднего бизнеса) - это признанный, наиболее дешевый и эффективный способ привлечения клиентов, при разумном использовании конечно.
Теперь мы хотим пойти дальше и пробить похожую тему у Яндекса. Надеемся что они пойдут на встречу, или у них что-нибудь есть похожее, о чем они скрывают. Откаты - это ведь очень по славянски.
понедельник, 26 мая 2008 г.
Разработка веб проекта после запуска (Agile 2.0)
Веб проекты уникальная вещь, намного более живая чем десктоп, здесь после запуска проекта в свет вы можете наблюдать за действиями пользователей в буквально реальном времени, если вы конечно об этом позаботились заранее.
Чем это хорошо - очень просто, любая новая функция добавленная в систему - это ваше предположение, гипотеза. А то как пользователь ее воспринимает - это реальность, если вы можете наблюдать за пользователем то вы увидите реальность очень быстро, и сможете ее исправить в случае, если она не похожа на то что вы предполагали. Это очень важно, так как в большинстве случаев разработчики (здесь и далее я не делю разработку на роли вроде девелопер, тим лид, продакт менеджер...) ошибаются. И самое главное, что они также в большинстве случаев ошибаются не сильно и эти ошибки очень легко исправить, нужно только об этом знать.
Вот поэтому от того, насколько вы позаботились о "наблюдаемости" вашей системы заранее, во многом зависит ваш успех, и то, как быстро вы займете нишу со своим продуктом. Более того, пользователи, которые привыкли к тому что изменения в систему привносятся медленно, увидев исправленную проблему через 15 минут после того как они сообщили проблему (или не сообщили и вы увидели ее из логов, или попросили небольшое изменение), приходят в полный восторг и думают - "эти парни наверное неплохо разбираются в своем деле". Таким образом из ошибки на сайте вы можете получить лояльных пользователей - ядро любой системы в современном мире (чуть не сказал web 2.0 мире, но мы не об этом).
Главное для вас на старте - обеспечить работу основных сценариев, и быть готовым к тому чтобы наблюдать за пользователями и мгновенно реагировать. Этой возможностью ("живым" наблюдением за пользователем и таким же "живым" процессом изменения) и отличается веб проект и это стоит это учитывать при его разработке.
То о чем я буду рассказывать дальше можно также назвать как разработку без тестирования. Да у нас его нет, у нас нет должности тестера и наверное не скоро появится, потому что он нам не нужен, как нам не нужен и продакт менеджер, наши пользователи для нас и то и другое. На самом деле у нас сотни тестеров и сотни продакт менеджеров - это те люди для которых писался этот сервис. Все что мы делаем это смотрим за ними и реагируем на их поведением, улучшая каждый день. Пользователи и разработчики при такой модели, тесно взаимодействуют друг с другом образуя подобие живого организма, и, как следствие, мы имеем чрезвычайно быструю эволюцию проектов. То что для больших проектов или десктоп приложений занимает месяцы и годы можно уместить в дни и недели.
Как это обеспечить? Все достаточно просто, начнем с наблюдаемости. Вы должны иметь возможность (и желание) наблюдать на за пользователями как на макро так и на микро уровне.
Макро уровень - это Google Analytics, AWStats, внутренние статистики (количество регистраций в день и т. д.). Эти инструменты позволят вам знать так называемую среднюю температуру по палате, и при наличии отклонений копнуть немного вглубь причин (например всплески активности, частоты индексации различными поисковиками, тенденции посещаемости по дням, популярные страницы). Кроме того, с помощью Google Analytics можно следить за конверсией пользователей, настроив правильным образом цели, в этом случае вы получите возможность знать насколько эффективны те или иные способы рекламы. Наблюдая за 404 ошибками в AWStats вы сможете найти битые ссылки в вашем проекте и т. д. Словом макро уровень это то, что обычно показывают топ менеджменту на презентациях результатов работы, но зачастую эти инструменты позволяют давать и более глубокую статистику, нужно только уметь грамотно ими пользоваться.
Микро уровень - это логирование, начиная от access logs вашего сервера и заканчивая... впрочем конца здесь нет, помните старую шутку про войну слоганов - "Яндекс - найдется все, Гугл - а ничего и не терялось", вы должны стремиться к тому чтобы не терять важную информацию о действиях пользователя. Храните все, код рекламной кампании с которой пришел пользователь, http referer - адрес сайта с которого он перешел к вам и стал вашим клиентом, при возникновении ошибки на сайте присылайте на емейл всю информацию о запросе, все http заголовки, полный stack trace ошибки. Невозможно все предусмотреть заранее, но вы должны пользоваться следующим правилом, если произошла ошибка и у вас нет достаточно информации чтобы узнать что именно произошло не так, не рвите на голове волосы, а добавьте необходимое логирование, не ленитесь, это действительно важно. В качестве примера приведу случай из нашей жизни. У нас стали попадаться на сайте картинки в каких-то непонятных цветах, изначально мы для экономии места все ужимали в 640 на 640, и, как следствие, потеряли оригиналы и не могли понять причину данного явления. Обнаружив это мы добавили код который сохраняет оригинал, и обнаружили ошибку с CMYK JPEG и PIL, которую исправили. (Правда теперь нам еще осталось написать простой cron скрипт который будет удалять все оригиналы старше недели, и к тому же выкинуть их из бекапов)
Помимо всего вышеперечисленного, организуйте наблюдаемость за результатом действий пользователей, мы это называем content feed. В нашей системе, все регистрации, добавления товаров, новостей, вакансий, и другие важные действия пользователей отдаются через RSS. В этот поток для каждой записи вы также можете вставить REST actions, например, заблокировать, активировать, пометить и прочее. Да, вы должны быть модераторами и поддержкой пользователей на ранней стадии жизни проекта, без этого вы просто не сможете написать инструментарий для людей которые будут этим заниматься впоследствии, когда проект разрастется. Вы должны есть еду вашей собаки, и она отплатит вам за это хорошей службой. К тому же чтение контента и общение с пользователями даст вам очень много ценных знаний о том как ваша система используется, что и где не так, даст почву для новых идей.
Не забудьте также про формы обратной связи и отчетах об ошибке на сайте, пользователи ими пользуются, и зачастую это очень полезные сведения. Да, это заставляет вас с ними общаться и отнимает немного времени, но это опять таки возможность получить лояльных пользователей в нашем пост-советском мире где само понятие сервиса появилось еще не везде.
Итак вы обеспечили наблюдаемость, что дальше - дальше нужно уметь реагировать на то что вы видите, иначе зачем все это. Время реакции на критичные вещи (проблемы в системе) должна равняться минутам, на менее критичные - часам и дням, это не значит что вы должны просыпаться ночью на выходных и чинить мелкую проблему, просто ваш процесс разработки должен позволять делать мелкие изменения на протяжении нескольких минут. То же самое и с новым функционалом, ваш процесс должен позволять добавить простую функцию в систему в считаные часы, но это не значит что все функции должны добавляться таким образом.
Что для этого нужно - во первых вы все должны быть ответственными и опытными разработчиками, это нужно для того чтобы система не приходила в негодность после мелких правок, так как невозможно за минуту сделать полное тестирование. Обычно при небольших изменениях в коде, вам нужно протестировать только ту небольшую функциональность, которую вы исправили, это должно вам дать 95 процентов уверенности в том что вы ничего не сломали вообще, для неопытного разработчика этот процент намного ниже. Что делать с остальными процентами? - Веб проект не атомная электростанция, если вы позаботились о наблюдаемости и можете внести изменения за пару минут то вы мало чем рискуете, проблема найдется и вы ее быстро исправите.
Таким образом это все дает возможность опытной команде разрабатывать вообще без классического тестирования как такового! Наш проект живет месяц, и я могу смело заявить что качество у нас не ниже чем было в моем прошлом проекте на старте, где соотношение тестеров и разработчиков было 2 к 3-м. Еще раз повторюсь, пользователи находят все, неподдерживаемые форматы, всевозможные варианты длин текстов, опечатки, проблемы с различными броузерами и прочее, и они приходят в экстаз когда вы исправляете это через 15 минут после извещения.
Очевидно, что для того чтобы этого достичь, обновление вашей системы до новой версии должно занимать секунды и минуты, и, в идеале, происходить практически незаметно для пользователя (сохранение сессий, незначительный down time). В нашем проекте в случае, когда не нужно вносить сложных изменений в базу данных, недоступность сервера занимает 2-3 секунды. А сам процесс обновления состоит в обновлении ветки SVN и перезапуске веб-сервера. Никаких тестов, никаких сборок, никаких кластеров. Залил изменение в SVN, запустил скрипт на сервере, проверил что все работает и через пару минут можно писать письмо пользователю, что его проблема устранена.
Но не стоит увлекаться и мелкими изменениями, система должна развиваться. Чтобы обеспечить это развитие для себя мы выделили 2 типа итераций (циклов) которые мы чередуем, - это итерации развития (ИР) и поддержания (ИП). ИР - это внесение нового функционала в проект, обычно длится у нас от 3-х до 7 рабочих дней, причем дата завершения плавающая, ее цель - внести в систему изменение. Это то, что в обычных проектах и понимается под итерацией. В начале ИР текущая версия уходит в live-ветку, в которой в дальнейшем исправляются все неотложные проблемы, а главная разработка идет в trunc-е. После ИР следует ИП - длится она 1-3 дня и состоит в том, что мы не ведем разработку в trunc-е а живем в live-ветке, наблюдаем за тем как приживается новый функционал и вносим изменения налету. В это время мы также дорабатываем дизайн, copy-тексты, мелкую логику, внутренние инструменты, статистики и прочие вещи которые не могут серьезно поломать систему. Как только мы довольны тем как работает новый функционал и нас начинает напрягать поддержка, мы сливаем все изменения в trunc и начинаем новую ИР.
Как результат, за 4 недели мы сделали 4 релиза (ИР) по такой модели и вполне довольны скоростью разработки, которая хоть сократилась, но зато функционал стал более акцентирован на пользователя, а не на сферического коня в вакууме. Мы стали любить и чувствовать наших пользователей, а они нас, и, признаться, это совсем другие ощущения, чем просто писать бездушный код.
Ограничения. Я думаю что это все работает на небольших командах (нас 3 человека) состоящих из опытных разработчиков, которые могут полностью доверять друг другу. Может это работает и в других случаях, но думаю тогда может появиться своя специфика. Это не работает в проектах основанных на технологиях где время от коммита до деплоймента превышает 10 минут. Ну и само по себе это не работает в аутсорсинговых проектах.
Спасибо за внимание, надеюсь что данная статья пригодится многим разработчикам, которые не занимаются привычным для нас аутсорсингом.
Вопросы, предложения, идеи как всегда приветствуются.
Чем это хорошо - очень просто, любая новая функция добавленная в систему - это ваше предположение, гипотеза. А то как пользователь ее воспринимает - это реальность, если вы можете наблюдать за пользователем то вы увидите реальность очень быстро, и сможете ее исправить в случае, если она не похожа на то что вы предполагали. Это очень важно, так как в большинстве случаев разработчики (здесь и далее я не делю разработку на роли вроде девелопер, тим лид, продакт менеджер...) ошибаются. И самое главное, что они также в большинстве случаев ошибаются не сильно и эти ошибки очень легко исправить, нужно только об этом знать.
Вот поэтому от того, насколько вы позаботились о "наблюдаемости" вашей системы заранее, во многом зависит ваш успех, и то, как быстро вы займете нишу со своим продуктом. Более того, пользователи, которые привыкли к тому что изменения в систему привносятся медленно, увидев исправленную проблему через 15 минут после того как они сообщили проблему (или не сообщили и вы увидели ее из логов, или попросили небольшое изменение), приходят в полный восторг и думают - "эти парни наверное неплохо разбираются в своем деле". Таким образом из ошибки на сайте вы можете получить лояльных пользователей - ядро любой системы в современном мире (чуть не сказал web 2.0 мире, но мы не об этом).
Главное для вас на старте - обеспечить работу основных сценариев, и быть готовым к тому чтобы наблюдать за пользователями и мгновенно реагировать. Этой возможностью ("живым" наблюдением за пользователем и таким же "живым" процессом изменения) и отличается веб проект и это стоит это учитывать при его разработке.
То о чем я буду рассказывать дальше можно также назвать как разработку без тестирования. Да у нас его нет, у нас нет должности тестера и наверное не скоро появится, потому что он нам не нужен, как нам не нужен и продакт менеджер, наши пользователи для нас и то и другое. На самом деле у нас сотни тестеров и сотни продакт менеджеров - это те люди для которых писался этот сервис. Все что мы делаем это смотрим за ними и реагируем на их поведением, улучшая каждый день. Пользователи и разработчики при такой модели, тесно взаимодействуют друг с другом образуя подобие живого организма, и, как следствие, мы имеем чрезвычайно быструю эволюцию проектов. То что для больших проектов или десктоп приложений занимает месяцы и годы можно уместить в дни и недели.
Как это обеспечить? Все достаточно просто, начнем с наблюдаемости. Вы должны иметь возможность (и желание) наблюдать на за пользователями как на макро так и на микро уровне.
Макро уровень - это Google Analytics, AWStats, внутренние статистики (количество регистраций в день и т. д.). Эти инструменты позволят вам знать так называемую среднюю температуру по палате, и при наличии отклонений копнуть немного вглубь причин (например всплески активности, частоты индексации различными поисковиками, тенденции посещаемости по дням, популярные страницы). Кроме того, с помощью Google Analytics можно следить за конверсией пользователей, настроив правильным образом цели, в этом случае вы получите возможность знать насколько эффективны те или иные способы рекламы. Наблюдая за 404 ошибками в AWStats вы сможете найти битые ссылки в вашем проекте и т. д. Словом макро уровень это то, что обычно показывают топ менеджменту на презентациях результатов работы, но зачастую эти инструменты позволяют давать и более глубокую статистику, нужно только уметь грамотно ими пользоваться.
Микро уровень - это логирование, начиная от access logs вашего сервера и заканчивая... впрочем конца здесь нет, помните старую шутку про войну слоганов - "Яндекс - найдется все, Гугл - а ничего и не терялось", вы должны стремиться к тому чтобы не терять важную информацию о действиях пользователя. Храните все, код рекламной кампании с которой пришел пользователь, http referer - адрес сайта с которого он перешел к вам и стал вашим клиентом, при возникновении ошибки на сайте присылайте на емейл всю информацию о запросе, все http заголовки, полный stack trace ошибки. Невозможно все предусмотреть заранее, но вы должны пользоваться следующим правилом, если произошла ошибка и у вас нет достаточно информации чтобы узнать что именно произошло не так, не рвите на голове волосы, а добавьте необходимое логирование, не ленитесь, это действительно важно. В качестве примера приведу случай из нашей жизни. У нас стали попадаться на сайте картинки в каких-то непонятных цветах, изначально мы для экономии места все ужимали в 640 на 640, и, как следствие, потеряли оригиналы и не могли понять причину данного явления. Обнаружив это мы добавили код который сохраняет оригинал, и обнаружили ошибку с CMYK JPEG и PIL, которую исправили. (Правда теперь нам еще осталось написать простой cron скрипт который будет удалять все оригиналы старше недели, и к тому же выкинуть их из бекапов)
Помимо всего вышеперечисленного, организуйте наблюдаемость за результатом действий пользователей, мы это называем content feed. В нашей системе, все регистрации, добавления товаров, новостей, вакансий, и другие важные действия пользователей отдаются через RSS. В этот поток для каждой записи вы также можете вставить REST actions, например, заблокировать, активировать, пометить и прочее. Да, вы должны быть модераторами и поддержкой пользователей на ранней стадии жизни проекта, без этого вы просто не сможете написать инструментарий для людей которые будут этим заниматься впоследствии, когда проект разрастется. Вы должны есть еду вашей собаки, и она отплатит вам за это хорошей службой. К тому же чтение контента и общение с пользователями даст вам очень много ценных знаний о том как ваша система используется, что и где не так, даст почву для новых идей.
Не забудьте также про формы обратной связи и отчетах об ошибке на сайте, пользователи ими пользуются, и зачастую это очень полезные сведения. Да, это заставляет вас с ними общаться и отнимает немного времени, но это опять таки возможность получить лояльных пользователей в нашем пост-советском мире где само понятие сервиса появилось еще не везде.
Итак вы обеспечили наблюдаемость, что дальше - дальше нужно уметь реагировать на то что вы видите, иначе зачем все это. Время реакции на критичные вещи (проблемы в системе) должна равняться минутам, на менее критичные - часам и дням, это не значит что вы должны просыпаться ночью на выходных и чинить мелкую проблему, просто ваш процесс разработки должен позволять делать мелкие изменения на протяжении нескольких минут. То же самое и с новым функционалом, ваш процесс должен позволять добавить простую функцию в систему в считаные часы, но это не значит что все функции должны добавляться таким образом.
Что для этого нужно - во первых вы все должны быть ответственными и опытными разработчиками, это нужно для того чтобы система не приходила в негодность после мелких правок, так как невозможно за минуту сделать полное тестирование. Обычно при небольших изменениях в коде, вам нужно протестировать только ту небольшую функциональность, которую вы исправили, это должно вам дать 95 процентов уверенности в том что вы ничего не сломали вообще, для неопытного разработчика этот процент намного ниже. Что делать с остальными процентами? - Веб проект не атомная электростанция, если вы позаботились о наблюдаемости и можете внести изменения за пару минут то вы мало чем рискуете, проблема найдется и вы ее быстро исправите.
Таким образом это все дает возможность опытной команде разрабатывать вообще без классического тестирования как такового! Наш проект живет месяц, и я могу смело заявить что качество у нас не ниже чем было в моем прошлом проекте на старте, где соотношение тестеров и разработчиков было 2 к 3-м. Еще раз повторюсь, пользователи находят все, неподдерживаемые форматы, всевозможные варианты длин текстов, опечатки, проблемы с различными броузерами и прочее, и они приходят в экстаз когда вы исправляете это через 15 минут после извещения.
Очевидно, что для того чтобы этого достичь, обновление вашей системы до новой версии должно занимать секунды и минуты, и, в идеале, происходить практически незаметно для пользователя (сохранение сессий, незначительный down time). В нашем проекте в случае, когда не нужно вносить сложных изменений в базу данных, недоступность сервера занимает 2-3 секунды. А сам процесс обновления состоит в обновлении ветки SVN и перезапуске веб-сервера. Никаких тестов, никаких сборок, никаких кластеров. Залил изменение в SVN, запустил скрипт на сервере, проверил что все работает и через пару минут можно писать письмо пользователю, что его проблема устранена.
Но не стоит увлекаться и мелкими изменениями, система должна развиваться. Чтобы обеспечить это развитие для себя мы выделили 2 типа итераций (циклов) которые мы чередуем, - это итерации развития (ИР) и поддержания (ИП). ИР - это внесение нового функционала в проект, обычно длится у нас от 3-х до 7 рабочих дней, причем дата завершения плавающая, ее цель - внести в систему изменение. Это то, что в обычных проектах и понимается под итерацией. В начале ИР текущая версия уходит в live-ветку, в которой в дальнейшем исправляются все неотложные проблемы, а главная разработка идет в trunc-е. После ИР следует ИП - длится она 1-3 дня и состоит в том, что мы не ведем разработку в trunc-е а живем в live-ветке, наблюдаем за тем как приживается новый функционал и вносим изменения налету. В это время мы также дорабатываем дизайн, copy-тексты, мелкую логику, внутренние инструменты, статистики и прочие вещи которые не могут серьезно поломать систему. Как только мы довольны тем как работает новый функционал и нас начинает напрягать поддержка, мы сливаем все изменения в trunc и начинаем новую ИР.
Как результат, за 4 недели мы сделали 4 релиза (ИР) по такой модели и вполне довольны скоростью разработки, которая хоть сократилась, но зато функционал стал более акцентирован на пользователя, а не на сферического коня в вакууме. Мы стали любить и чувствовать наших пользователей, а они нас, и, признаться, это совсем другие ощущения, чем просто писать бездушный код.
Ограничения. Я думаю что это все работает на небольших командах (нас 3 человека) состоящих из опытных разработчиков, которые могут полностью доверять друг другу. Может это работает и в других случаях, но думаю тогда может появиться своя специфика. Это не работает в проектах основанных на технологиях где время от коммита до деплоймента превышает 10 минут. Ну и само по себе это не работает в аутсорсинговых проектах.
Спасибо за внимание, надеюсь что данная статья пригодится многим разработчикам, которые не занимаются привычным для нас аутсорсингом.
Вопросы, предложения, идеи как всегда приветствуются.
понедельник, 19 мая 2008 г.
Еще один интересный вариант использования нашего сервиса
Не успели мы добавить новости и статьи компаний на прошлой неделе, как сегодня у нас на сайте повилась первая онлайн газета Аграрна Країна.
Поначалу мы хотели как-то вмешаться в такое использование сайта не по существу, но подумав поняли, что все что пользователи делают с любовью и в неких рамках приличия, не стоит порицать. Да и вообще, может они нам открыли небольшой новый рынок и мы с этого что нибудь сделаем в будущем.
Итак, с сегодняшнего дня мы еще и бесплатный хостинг для интернет изданий :)
Поначалу мы хотели как-то вмешаться в такое использование сайта не по существу, но подумав поняли, что все что пользователи делают с любовью и в неких рамках приличия, не стоит порицать. Да и вообще, может они нам открыли небольшой новый рынок и мы с этого что нибудь сделаем в будущем.
Итак, с сегодняшнего дня мы еще и бесплатный хостинг для интернет изданий :)
пятница, 9 мая 2008 г.
13 советов для создания успешного проекта
Daniel Tenner написал просто отличную статью про то как повысить свои шансы на успех создавая новый онлайн проект. Кстати многое их этого, наверное, применимо и к другим видам бизнеса.
Комментировать и резюмировать особо нечего, надо читать. Из кучи околостартапного чтива, которого в последнее время я читаю довольно много, это действительно очень стоящая статья, много из того что там написано мы осознали на своем опыте за последние 4 месяца, и особенно 3 недели после выхода проекта в свет.
Любите своих пользователей.
Комментировать и резюмировать особо нечего, надо читать. Из кучи околостартапного чтива, которого в последнее время я читаю довольно много, это действительно очень стоящая статья, много из того что там написано мы осознали на своем опыте за последние 4 месяца, и особенно 3 недели после выхода проекта в свет.
Любите своих пользователей.
Как настроить бекап Mac OS 10.5.2 (Leopard) на сетевой диск
После перепетий с ноутбуком Тараса я решил, от греха подальше, настроить бекап своего Mac Book Pro на домашний сетевой диск My Book World. Оказалось что все не так просто и Apple сделал много преград для того чтобы усложнить жизнь людям которые не хотят покупать Time Capsule (я бы может ее и купил, но у меня уже есть и точка доступа и My Book World 500G)
Итак как это сделать.
Прежде всего нужно отключить проверку совместимости вашего хранилища с Time Machine для этого наберите в терминале:
defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
Дальше если у вас версия Mac OS < 10.5.2 то вы почти у цели, дело в том что при указании сетевого диска отличного от устройства Time Capsule Mac OS 10.5.2 отказывается создавать раздел (.sparsebundle файл) причем в случае если бекап был настроен ранее (например в 1.5.1 версии) то все работает. Побороть это довольно просто, нужно создать этот раздел вручную утилитой hdiutil и скопировать в корень сетевого диска, убедившись что вы можете туда писать и читать.
Команда выглядит следующим образом (для моего ноутбука)
hdiutil create -size 90G -fs HFS+J -type SPARSEBUNDLE "mpmac_001b63b72ded.sparsebundle"
Здесь
mpmac - Это имя моего ноута (задается в System Preferences->Sharing) рекомендуют использовать имена покороче и без спец символов во избежание некоторых косяков.
001b63b72ded - это мой MAC адрес без : разделителей (можно узнать из System Preferences->Network->Ethernet->Ethernet ID)
90G - это максимальный размер в гигабайтах (естественно файл будет расширяться динамически, начальный размер у меня был примерно 80М)
Далее вы копируете этот файл в корень вашего сетевого диска и в утилите Time Machine выбираете диском для хранения бекапа ваш сетевой диск. 6-8 часов и ваши данные надежно забекаплены
Ссылки:
Как это было просто до 10.5.2
http://www.macosxhints.com/article.php?story=20080420211034137
http://discussions.apple.com/thread.jspa?threadID=1393882&tstart=15
вторник, 6 мая 2008 г.
Продолжение истории с Бегуном
Начало
написанного в воскресенье вечером, кампания включилась и начала работать в понедельник утром, о чем меня конечно же никто не уведомил. Действительно а зачем? Мы должны продолжать нести гордое знамя быдло-сервиса.
Ну вобщем запустилось оно, и даже люди стали по объявлениям кликать и регестрироваться, ну собственно за тем и делалось. И тут я решил поправить объявление и добавить пару новых слов... Я не знаю кто им писал этот интерфейс но уверен что этот человек никогда не пробовал им пользоваться, ибо отредактировать объявление невозможно, сразу же после создания оно разбивается на N отдельных объявлений где N - это количество ключевых слов, мудро не так ли? То есть мне нужно было уже отредактировать 20 объявлений, и тут мы приходим к цыганской дилеме - этих отмыть или новых нарожать, я решил пойти по второму пути, так как это быстрее, думаю так поступает большинство людей. Кстати спасибо им что хоть ставки можно менять на одном экране.
Я просто создал рядом другое объявление и ввел новые слова. И тут я прозрел во второй раз. Нет все добавилось отлично, но я просто такой нехороший лентяй, вместо того чтобы ввести слова с разделителем я ввел их с разделителем и еще запятой, ну я их так храню ибо так понимает и яндекс и гугл, Бегун так не понял, точнее не Бегун, он мне ничего не сказал, не поняло их два милых создания работающие модераторами. Природный интеллект.
Итак за следующий час Мне пришло порядка 10-ти писем от двух модераторш с уведомлениями о непрохождении моими объявлениями модерации. Вот некоторые из формулировок:
И все из-за какой-то запятой. Да я ступил, точнее подумал что в 21-м веке программисты дошли до уровня когда они могут автоматом корректировать примитивные ошибки. Я сделал это полу-преднамеренно мне было интересно и слегка лениво удалять запятые, но я никогда бы не подумал что реакция может быть настолько неадекватной, интересно а хоть окончания в словах они отрезают, или желтая страница у них != желтые страницы?
Вобщем плохой сервис, на уровне жеков, где при наличии ошибки в справке, незначительной, вас посылают делать все по новой. А жаль, ведь люди то кликают :)
Вот думаю что им написать на этот раз? Думаю продолжение не заставит себя ждать, я человек настойчивый и Бегун очень интересный феномен для исследования.
Итак после письма в службу поддержки следующего содержания:
Меня кинули на 20 долларов? или на выходных у вас модераторы были не в себе, но я бы уволил нафиг человека за такое письмо клиенту, спасибо еще раз за ваш отличный быдло-сервис.
Верните пожалуйста 20 долларов на карточку, или включите объявление, оно правильное и прошло модерацию по этим словам в яндекс директе и гугл эдвордс, да я знаю что они лохи а вы нет но все же.
Желаю вам больше не огорчать так своих клиентов. Исправьтесь или умрите.
написанного в воскресенье вечером, кампания включилась и начала работать в понедельник утром, о чем меня конечно же никто не уведомил. Действительно а зачем? Мы должны продолжать нести гордое знамя быдло-сервиса.
Ну вобщем запустилось оно, и даже люди стали по объявлениям кликать и регестрироваться, ну собственно за тем и делалось. И тут я решил поправить объявление и добавить пару новых слов... Я не знаю кто им писал этот интерфейс но уверен что этот человек никогда не пробовал им пользоваться, ибо отредактировать объявление невозможно, сразу же после создания оно разбивается на N отдельных объявлений где N - это количество ключевых слов, мудро не так ли? То есть мне нужно было уже отредактировать 20 объявлений, и тут мы приходим к цыганской дилеме - этих отмыть или новых нарожать, я решил пойти по второму пути, так как это быстрее, думаю так поступает большинство людей. Кстати спасибо им что хоть ставки можно менять на одном экране.
Я просто создал рядом другое объявление и ввел новые слова. И тут я прозрел во второй раз. Нет все добавилось отлично, но я просто такой нехороший лентяй, вместо того чтобы ввести слова с разделителем
Итак за следующий час Мне пришло порядка 10-ти писем от двух модераторш с уведомлениями о непрохождении моими объявлениями модерации. Вот некоторые из формулировок:
К сожалению, объявление по ключевому слову «справочник предприятий россии,» не прошло модерацию, по следующей причине:
Поле ключевое слово заполнено неверно. Контекстные ключевые слова и словосочетания должны разделяться между собой через Enter. Наиболее длинные ключевые словосочетания рекомендуется разбивать на несколько частей.
К сожалению, объявление по ключевому слову «каталог сайтов,» не прошло модерацию, по следующей причине:
При составлении объявления необходимо учитывать правила орфографии и пунктуации. Между словами в тексте объявления допускается использование не более одного пробела. После знаков препинания обязательно ставится один пробел.
К сожалению, объявление по ключевому слову «рейтинг предприятий,» не прошло модерацию, по следующей причине:
Текст объявления не содержит достаточной информации о рекламируемых товарах и услугах. Пожалуйста, заполните поля «заголовок» и «описание» более подробно.
И все из-за какой-то запятой. Да я ступил, точнее подумал что в 21-м веке программисты дошли до уровня когда они могут автоматом корректировать примитивные ошибки. Я сделал это полу-преднамеренно мне было интересно и слегка лениво удалять запятые, но я никогда бы не подумал что реакция может быть настолько неадекватной, интересно а хоть окончания в словах они отрезают, или желтая страница у них != желтые страницы?
Вобщем плохой сервис, на уровне жеков, где при наличии ошибки в справке, незначительной, вас посылают делать все по новой. А жаль, ведь люди то кликают :)
Вот думаю что им написать на этот раз? Думаю продолжение не заставит себя ждать, я человек настойчивый и Бегун очень интересный феномен для исследования.
воскресенье, 4 мая 2008 г.
Не пользуйтесь Бегуном (рассказ обманутого пользователя)
Итак после размещения объявлений на Яндексе и Гугле я решил попробовать Бегун, так чисто для интереса а может Рамблер наконец-то сделал что-то хорошее. Зря.
Началось все с самого убогого интерфейса создания кампании, который я со скрипом прошел, настроил цены и, заплатив 20 долларов по карточке, получил ответ что в течении дня (как потом оказалось потом из письма ответа - это означает бизнес дня) они будут зачислены на счет.
На следующий день денег там не оказалось, написав письмо в службу поддержки я в 9 утра следующего дня (в воскресенье!!!) получил в постель звонок некой барышни которая представившись Бегуном спросила мой логин и сколько я платил денег. Я ей ответил - она сказала все ОК и попрощалась, зачем им это надо я не успел спросить и до сих пор нахожусь в недоумении. Дальше было интереснее, днем я получил письмо следующего содержания:
Текст объявления
Объявление прошло до этого модерацию гуглом и яндексом, а какой-то бегун считает что оно плохое сославшись на:
"Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин."
Я им написал прямо что они ох..ели и потребовал вернуть деньги на карточку.
Вот такой вот негативный юзер експириенс, по сути меня кинули на 20 баксов так как думаю что деньги они мне не вернут, но зато они получили в свои ряды еще одного поклонника своего прекрасного сервиса. Я ума не приложу как такие компании выживают на рынке?
ЗЫ. Еще раз респект яндекс директу в этой области, о том чем он лучше всех (все - это наверное только гугл эдвордс после очень ) в СНГ я постараюсь рассказать позже когда закончим наши эксперименты.
Началось все с самого убогого интерфейса создания кампании, который я со скрипом прошел, настроил цены и, заплатив 20 долларов по карточке, получил ответ что в течении дня (как потом оказалось потом из письма ответа - это означает бизнес дня) они будут зачислены на счет.
На следующий день денег там не оказалось, написав письмо в службу поддержки я в 9 утра следующего дня (в воскресенье!!!) получил в постель звонок некой барышни которая представившись Бегуном спросила мой логин и сколько я платил денег. Я ей ответил - она сказала все ОК и попрощалась, зачем им это надо я не успел спросить и до сих пор нахожусь в недоумении. Дальше было интереснее, днем я получил письмо следующего содержания:
Добрый день!
Вы создали рекламные объявления на сайте www.begun.ru
Рекламная кампания: Нужны клиенты?
К сожалению, объявление по ключевому слову «Желтые страницы» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «бизнес каталог» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «бизнес справочник» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «доски объявлений» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «заказ сайта» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «как привлечь клиентов» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «как создать интернет магазин» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «как создать сайт бесплатно» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «каталог компаний» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «каталог организаций» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «каталог фирм» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «нужен сайт» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «поиск клиентов» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «предприятия россии» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «привлечение клиентов» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «привлечение новых клиентов» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «сделать сайт бесплатно» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «список компаний» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «способы привлечения клиентов» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
- объявление по ключевому слову «справочник предприятий» не прошло модерацию, по следующей причине:
Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин.
Доступ к Вашему аккаунту и средства на счету сохраняются. Вы можете использовать их
для проведения рекламной кампании соответствующей требованиям.
Внести изменения в объявления Вы можете в интерфейсе рекламной
кампании, раздел "Ставки", "Редактировать".
Ознакомиться с требованиями к информационным материалам Вы можете
перейдя по ссылке http://legal.begun.ru/client/sogl-1.pdf
С уважением, модератор компании "Бегун"
support@begun.ru | (495) 956-9007
Текст объявления
Нужны клиенты?
Начните продавать через интернет за 10 минут прямо сейчас.
ruprom.net
Объявление прошло до этого модерацию гуглом и яндексом, а какой-то бегун считает что оно плохое сославшись на:
"Компания «Бегун» оставляет за собой право отклонить любой информационный материал без объяснения причин."
Я им написал прямо что они ох..ели и потребовал вернуть деньги на карточку.
Вот такой вот негативный юзер експириенс, по сути меня кинули на 20 баксов так как думаю что деньги они мне не вернут, но зато они получили в свои ряды еще одного поклонника своего прекрасного сервиса. Я ума не приложу как такие компании выживают на рынке?
ЗЫ. Еще раз респект яндекс директу в этой области, о том чем он лучше всех (все - это наверное только гугл эдвордс после очень ) в СНГ я постараюсь рассказать позже когда закончим наши эксперименты.
пятница, 2 мая 2008 г.
Python выиграл Linux Journal Readers' Choice Awards 2008 в категории скриптовых языков
Favorite Scripting Language
Python (28.9%)
Honorable Mentions
PHP (21.7%)
bash (19.8%)
Perl (17%)
It's no surprise that Python grabbed top honors in the Favorite Scripting Language category, and that PHP, bash and Perl all deserve honorable mention for their strong showings.
Полный список победителей здесь
Рейтинги вещь субъективная, но все же порадуемся за хороший язык.
Кстати субъективность рейтингов подтверждает безоговорочное первое место MySQL и Apache, а также первое место C как языка программирования (немного опередив плюсы и Java).
Писать на С очень сложно что признают практически все кто на нем пишет, Apache давно проигрывает более легковесным lighttpd и nginx в плане удобства, производительности и количества уязвимостей, а MySQL по сравнению с PostgreSQL выглядит пионерской базой данных из-за нестандартного синтаксиса, неудобства администрирования и абсолютно неудобным (чтоб не сказать хуже) механизмом встроенных процедур, не говоря уже о производительности.
четверг, 1 мая 2008 г.
Гугл AdWords жульничает?
Многие меня знают как человека более чем лояльного к Гуглу, но сегодня я окончательно них разочаровался. Дело было так:
Вчера днем я настроил AdWords а показ рекламы своего сайта в поиске по ключевым словам одним из которых было "желтые страницы", система сказала плати 15 центов в Украине и 8 в России и будешь в поиске, я сказал ОК и все заработало, по рекламе правда никто не кликал но то мелочи она показывалась и я это видел (было за вчера 400 показов).
Сегодня я зашел проверить улов и обнаружил что в поиске меня нет ни по желтым страницам ни по всем другим словам (5-6) по которым я вчера поставил 10-15 центов чтобы быть в нем. За день цены выросли в 2-3 раза (инфляция чтоли?). Желтые страницы подорожали до 40 центов и... там сейчас показывается только реклама AdWords. Вот такая вот честная конкуренция, то есть Гуглу не нужны мои 15 центов они хотят 40 а иначе все кликаем на AdWords.
А теперь вспоминаем мартовский пост и убеждаемся что дыма без огня не бывает. Что нас ждет в будущем загадка, так что хорошо что есть Яндекс с его Директом и вообще поиском, но что делать людям вне СНГ с таким вот внезапными обострениями со стороны интернет компании №1?
Может я не прав и это нормально душить конкурентов в "своих" ключевых словах, вы как думаете?
Вчера днем я настроил AdWords а показ рекламы своего сайта в поиске по ключевым словам одним из которых было "желтые страницы", система сказала плати 15 центов в Украине и 8 в России и будешь в поиске, я сказал ОК и все заработало, по рекламе правда никто не кликал но то мелочи она показывалась и я это видел (было за вчера 400 показов).
Сегодня я зашел проверить улов и обнаружил что в поиске меня нет ни по желтым страницам ни по всем другим словам (5-6) по которым я вчера поставил 10-15 центов чтобы быть в нем. За день цены выросли в 2-3 раза (инфляция чтоли?). Желтые страницы подорожали до 40 центов и... там сейчас показывается только реклама AdWords. Вот такая вот честная конкуренция, то есть Гуглу не нужны мои 15 центов они хотят 40 а иначе все кликаем на AdWords.
А теперь вспоминаем мартовский пост и убеждаемся что дыма без огня не бывает. Что нас ждет в будущем загадка, так что хорошо что есть Яндекс с его Директом и вообще поиском, но что делать людям вне СНГ с таким вот внезапными обострениями со стороны интернет компании №1?
Может я не прав и это нормально душить конкурентов в "своих" ключевых словах, вы как думаете?
Подписаться на:
Сообщения (Atom)