Очень часто бывает так, что владелец интернет-магазина выделяет огромные деньги на рекламу — размещает свои товары в торговых сетях, даёт объявления в системах контекстной рекламы, ставит баннеры на сайтах близких по тематике. Все это, безусловно, привлекает огромное количество посетителей, но проблема в том, что лишь ничтожно малая часть из них действительно совершает заказ. Именно этой проблеме и посвящена данная статья.

Многим разработчикам знакома ситуация когда кешировать страницы сайта, скажем, на 5-10 минут нельзя всего из-за одного небольшого блочка, актуальность которого нужно поддерживать если не в реальном времени, то с временем «старения» не больше 5-10 секунд. При этом посещаемость сайта продолжает расти, растет время генерации страниц и c этим надо что-то делать…

• Вариант решения 1: Подкрутить то, до чего не доходили руки последнее полгода. Все Вас поймут и передвинут сроки на другие задачи. Вы будете в роли «Супермена» один спасать сайт от непомерной нагрузки, решая проблему «бесплатно» (без доп. вливаний в оборудование). Вам может пригодиться статья «Тюнинг nginx».
   
• Вариант решения 2: Улучшить техническую базу (докупить мозгов на сервер, улучшить дисковую систему, поставить под БД отдельный сервер). В принципе проблема не решена, а скорее отложена. Теперь у Вас есть время «окопаться» и подготовиться ко второй волне наплыва нагрузки, она будет больше и накроет сильнее.
   
• Вариант решения 3: Ваш вариант, о котором я, вероятно, узнаю из комментариев.
   

Позвольте предложить и мне проверенное и относительно простое решение на базе одной из старейших технологий в Web-разработке.

Давайте уделим немного внимания старому доброму текстовому редактору Gedit. Он является дефолтным текстовым редактором для большинства Linux-дистрибутивов использующих Gnome в качестве оконного менеджера. Как выяснилось, и как мы в дальнейшем убедимся, Gedit поддерживает плагины, в числе которых есть много полезных и интересных.

Что такое веб-сервисы?

Прежде всего, веб-сервисы (или веб-службы) — это технология. И как и любая другая технология, они имеют довольно четко очерченную среду применения.

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

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

Я затвитил эту статью о 5 причинах проводить обзоры кода на CIO.com на прошлой неделе и понял, что на самом деле причин гораздо больше, чем те пять, о которых там написано. Так что к концу дня у меня их было уже больше 20. Это коллекция тех твитов с некоторыми подробностями, описанными здесь.

Причина №1. Достаточно быстрая ответная реакция, чтобы подстегнуть разработчика.
Так как обзор кода производится после кодирования и перед интеграционными и системными тестами, разработчикам не надо ждать столько же, сколько и ответа от отдела по качеству кода (QA). Обеспечив конкретный, своевременный ответ, разработчики могут подстраивать свои навыки кодирования для избежания общих ошибок.

Ох этот скромный {% if %}. Краеугольный камень шаблоной логики Django.

Каждый, кто начинал работать с Django 1.1 (или ранее), почти наверняка спотыкался об этот камень — шаблонный тег {% if %} поддерживает булеву логику только на базовом уровне.

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

Идущее в поставке с Django приложение аутентификации и авторизации (django.contrib.auth) всегда включало базовый функционал для отображения всплывающих сообщений пользователю, но он имел несколько досадных недостатков. В Django 1.2 же теперь есть совершенно новый фреймворк для таких сообщений, написанный в первую очередь Тобаясом Макналти (Tobias McNulty).

Это вторая статья о становлении софтверного (интернет-) бизнеса в России (первая тут). В ней я собираюсь раскрыть некоторые ключевые моменты адаптации продукта под рынок (под требования пользователей), о преодолении тенологической пропасти, и чуть-чуть о реалиях российского бизнеса.

Данный топик хочу приурочить к тому, что год назад (может, чуть раньше или чуть позже) появился продукт WEBO Site SpeedUp (ранее Web Optimizer). Мысли немного сумбурны, но, видимо, для каждого направления все сильно специфично, поэтому ценными будут только общие идеи, направления и подходы к решению проблем (в чем я искренне надеюсь :). Здесь и далее речь идет о создании коробочного решения (а не софтверном аутсорсе).

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

Зачем нужен этот топик? Чтобы после прочтения можно было однозначно ответить на вопросы «А оно мне надо?», «Стоит ли переводить проект в разряд стартапа (или наоборот)?», «Как заработать на своем труде в России?» и на ряд других более конкретно. И это только касательно России (если все будет хорошо, то выложу аналогичный топик и относительно международного софтверного бизнеса).

Внимание: вся нижеприведенная информация изложена с позиций минимизации затраченного времени (и увеличения надежности мероприятия) и с учетом отсутствия прописки в городе регистрации юр. лица (и отсутствия рабочего офиса).

Продукт и команда

Перед стартом обязательно имейте хотя бы что-нибудь. Что-нибудь, что приносит деньги. Без денежного потока (пусть даже в 10-20 тысяч рублей) затевать все это бессмысленно (далее будет понятно, почему, но первичные расходы на оформление всей волокиты составляют порядка 30к рублей). Естественно, открывать свое юридическое лицо и оформлять бизнес стоит в том случае, если вы собираетесь расти. И не просто расти, а очень сильно расти. Иметь оборот в 20-30 тысяч рублей можно и не имея никакого юридического лица, а при «нелегальном» обороте в районе 100 тысяч уже могут начаться различные проблемы с государством (и красиво оформить это может уже не получиться).

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

Ладно, вроде у нас есть, что продавать (будь это хоть утилита «Time Machine для Windows»). У нас есть пара человек, которые разделяют ответственность за компанию и готовы работать во имя ее успешности. Что дальше?

Дальше самое интересное.

Недавно я и Тимур Гаффоров запустили наш новый сервис для генерации иконок Iconizer.net.



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

Сервис немного похож на наш Preloaders.net, так как выполняет похожие функции. Но, самое главное, он перенял с него простоту дизайна и легкость использования.

Язык PHP очень легок для изучения. Это, а так же обилие литературы «Освой _что_угодно_ за 24 часа» породило большое количество, мягко говоря, некачественного кода. Как следствие, рано или поздно любой программист, который выходит за рамки создания гостевой книги или сайта-визитки сталкивается с вопросом: «а если я здесь немножко добавлю, все остальное не ляжет?» Дать ответ на этот вопрос и на многие другие может юнит-тестирование.

В самом начале хочется оговориться — здесь речь не будет идти о TDD и методологиях разработки ПО. В данной статье я попробую показать начинающему PHP-разработчику основы использования модульного тестирования на базе фреймворка PHPUnit

Когда-то я уже писал, как интегрировать OpenID авторизацию в ваш сайт. Речь шла о серверной части.
Сейчас же я говорю о UI части — виджет для выбора провайдера.

В качестве клиентской библиотеки для своего проекта я выбрал prototype и первым делом я полез в гугл поискать готовое решение. Удалось найти такое, но только для JQuery — code.google.com/p/openid-selector

И так мне ничего не оставалось как написать OpenID selector самому. Вот что получилось

2 года назад в рунете был только один онлайн-сервис тестов по билетам ГИБДД и пара stand-alone приложений. Теперь же таких сервисов несколько десятков и конкуренция за аудиторию поистине огромна.
Сегодня мы расскажем на примере самого популярного из них (acars.ru/pdd) и том, как этого добились.

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

Как то я уже писал топик про каптчу 3D

А вчера решил слегка переделать, добавить рюшечек и еще одно измерение.
Долго сказка пишется, да быстро дело делается, рушил сделал и вот наваял гиперкуб Капчу 4D.

Публикуется по просьбе mdss, который доработал мою версию заглушки для IE6.
Все благодарности лично ему.

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

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

Что мы делаем когда закрадывается смутное предположение, что компания скачет на мёртвой лошади:

[ Индикаторы класса «Возможны ложные срабатывания» ]
— Мы достаём более хлёсткий и мощный кнут для мёртвой лошади (а нередко и на конюхов розг хватает)
— Ждём, ничего не делаем, ведь мы всегда точно так ездили на мёртвых лошадях и раньше проблем не было
— Меняем наездника. Когда мёртвая лошадь не скачет виноват обычно он
— Облагораживаем стойло, достаём конюхам пряников
— Едем за бугор, там с незапамятных времён водились наездники на мёртвых лошадях, перенимаем их опыт
— В добровольно-принудительном порядке предлагаем курсы верховой езды сотрудникам отдела
— Создаём группу и анализируем мёртвую лошадь, время смерти и меру окоченения
— Признаём мёртвую лошадь неверно аттестованной, она живее всех живых

Более веские приметы под катом

Прошелся по закладкам и образовалась такая толстенькая подборочка ресурсов с бесплатными и качественными иконками, с которой спешу поделиться с тобой %username%!

Iconfinder

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



Чтобы ответить на него обращу ваше внимание на структуру рабочего времени, в течение которого руководитель вступает в отношения трех типов — с начальством, с руководителями других отделов (менеджерами) и подчиненными. Поэтому и время разделим на три компонента:

1. Время менеджера, которым распоряжается босс, — это время расходуется на деятельность, навязываемую начальством. «Проколоться» здесь нельзя — будете наказаны.

2. Время, которое забирает система, — работа с руководителями других подразделений и внутренняя текущая деятельность. «Забьете» на нее — беды не избежать, просто оно может быть отложено во времени.

3. Время, которое тратится на собственные инициативы, — эта часть тратится на то, что вы делаете добровольно. Однако именно это время любят съедать подчиненные, так что распоряжаться самостоятельно вы можете только тем, что сможете организовать себе сами. Как? Минимизировать или свести практически к нулю время, сжираемое подчиненными.

Вот это сюрприз! Тобиас Шнайдер (Tobias Schneider) построил среду исполнения Flash, работающую прямо во браузере. Она реализована на чистом джаваскрипте и HTML5, и все исходники являются открытыми (MIT-лицензированными), и располагаются на GitHub.

Поглядите на Gordon в действии (хостинг демонстраций осуществил Пол Айриш).

Gordon работает волшебно в последних версиях Файерфокса, Хрома и Сафари (да, и в iPhone Safari, хотя демонстрация «blue» на моём 3G идёт утомительно медленно). Чтобы установить его себе, запустите «git clone git://github.com/tobeytailor/gordon.git». Я обнаружил, что с URL «file:///» демонстрации не грузятся (в силу системы зависимостей скрипта), так что направьте ваш вебосервер на корень Gordon, а браузер направьте на demos/.

Документации ещё никакой нету, так что неясно, насколько широкой совместимостью с Flash обладает Gordon, или в каком направлении станет развиваться. Однако, по крайней мере, это мощная заявка на зрелость открытых веботехнологий.

<body onload="new Gordon.Movie('trip.swf', {id: 'stage', width: 500, height: 400})"></a>
    <div id="stage"></a></div>
</body>