Ничто меня не бесит так, как автореспондеры. После каждой рассылки насыпается пара сотен автоматических ответов. Я получил ваше письмо, я не получил, но получу и прочту, меня нет на месте, наш специалист свяжется с вами, я в отпуске, я родил малыша, я уволился. Да кому какое дело, что там у тебя. Не о тебе речь вообще.

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

1. Джерри и Адриана

Джерри - разработчик приложений для iPhone. Путешествует с женой Адрианой, работает откуда придется и у него это неплохо получается.

2. The Unstoppable family

Вы скажете стиль жизнь-путешествие не подходит для семейных пар с детьми и будете в чем-то правы. Но Unstoppable family путешествует с дочерью уже три года и все у них получается. Дочь ходит в школы, там где они живут в данный момент и так же занимаются домашним обучением.

Советую посмотреть вопросы и ответы. Самым полезным для путешествий иностранным языком они считают испанский.

Зарабатывают они на жизнь какой-то мутной ерундой типа MLM, но в остальном интересно почитать.

3. Аджей и Маша

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

4. Другая жизнь

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

Рекомендую почитать про восхождение на Килиманджаро, впечатляет.

5. Shooow me

Владимир и Ольга совмещают приятное с полезным, путешествуют, ведут журнал и находят спонсоров, которые им помогают со всеми этими делами. Вернулись из путешествия по Юго-Востоной Азии и планируют путешествие в Южную Америку.

А что тебе не дает сорваться с места прямо сейчас?

Размышлизмы, навеянные рассылками по клиентской базе.

1. Распродажи аля Groupon работают

Спасибо Групону, народ привык покупать всякую малонужную ерунду со значительной скидкой в надежде когда-нибудь воспользоваться ей. Рецепт: возьмите пару-тройку своих продуктов, которые продаются слабо,  объедините их в бандл, сделайте скидку процентов 60-80 и сделайте рассылку по списку клиентов. Для убедительности ограничьте срок действия распродажи и повесьте часы с обратным отсчетом.

Главное не увлечься и не включать продукты, которые и так хорошо продаются, залезете себе в карман. Работает как часы.

2. Повторенье - мать ученья

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

3. Как понимать клиентов.

Это самое интересное. Разговор с клиентом больше всего напоминает общение с женщиной. Думает одно, говорит другое, а ожидает от тебя третьего.

Клиент говорит: хочу чтобы было такое место, где люди могут обмениваться своими шаблонами.

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

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

Чтобы подстегнуть процесс создания иобмена стилями запустили конкурс. Нужно сделать свой стиль и прислать его нам. Сроку дали десять дней. Десять лучших стилей получают по 100 долларов каждый. В принципе не так плохо за пару часов работы.

Повторюсь, нужно просто делать то, что ты обычно делаешь, просто прислать файлы стилей на конкурс и, с большой вероятностью, получить приз.   Рассылку получают несколько десятков тысяч человек. Результат: свои работы прислали три человека. Мораль придумайте сами.

Удачных вам рассылок!

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

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

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

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

"Не разорви цепочку", повторил он еще раз.

На протяжении многих лет я пользовался этой техникой в самых различных областях. Я использовал ее для физических упражнений, для изучения языков программирования , для построения вебсайтов и бизнесов.

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

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

Не разорви цепочку!

Источник: Lifehacker

------------------------------

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

Ссылки

Печально известный финансовый стартап Wesabe выложил исходники своего парсера сайтов банков и других финансовых организаций на Github. Вот тут немного дополнительной информации и обсуждение.

------------------------

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

Большинство примеров кода не привязаны к какому-либо конкретному языку программирования, но для наглядности я буду использовать PHP.

Итак, поехали.

1. SQL injection

Допустим у вас есть вебсайт с формой ввода имени пользователя. Для проверки наличия имени в базе данных  вы используте вот такой код:

$query = "SELECT * FROM `Users` WHERE UserName='" . $_POST["Username"]. "'";
mysql_query($query);

где $_POST["Username"] - введенное пользователем имя.

Пользователю достаточно ввести вот такое значение в поле Username

' or '1'='1

чтобы получился запрос, который всегда возвращает данные:

SELECT * FROM `Users` WHERE UserName = '' OR '1'='1'

Для тех баз данных, которые поддерживают выполнение несколько запросов в одном пакете, злоумышленник может исполнить запрос удаляющий или изменяющий данные.

Пример такого ввода:

a';DROP TABLE `Users`; SELECT * FROM `userinfo` WHERE 't' = 't

Запрос на выходе:

SELECT * FROM `Users` WHERE `UserName` = 'a';DROP TABLE `Users`; SELECT * FROM `userinfo` WHERE 't' = 't'

Два основных способа избежать SQL injection:

• параметризованные запросы

Наиболее надежный метод, но не всегда подходит. В PHP можно для этой цели использовать MySQLi

$stmt = $db->prepare('update people set name = ? where id = ?');
$stmt->bind_param('si',$name,$id);
$stmt->execute();

• escaping

В PHP для этого есть функция mysql_real_escape_string, которая заменит опасные символы на escape последовательности. Наш пример теперь будет выглядеть вот так:

$query = sprintf("SELECT * FROM `Users` WHERE UserName='%s'",
                  mysql_real_escape_string($_POST["Username"]));
mysql_query($query);
 

2. Сross Site Scripting (XSS)

XSS уязвимости могут быть подвержены динамические вебсайты, где пользователи вводят какие-то свои данные, которые потом будут показаны на странице: форумы, гостевые книги, комментарии блогам и другое. Идея XSS заключается во встраивании в текст комментария какого-то Javascript кода, который исполнится, когда страницу откроет другой пользователь.

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

Форма для ввода текста:

 
<form id="myFrom" action="showResults.php" method="post">
<div><textarea name="myText" rows="4" cols="30"></textarea>
<input type="submit" value="Submit" name="submit" /></div>
</form>
 

Файл showResults.php:

echo("You typed this:");
echo($_POST['myText']);

Мы видим, что введенный текст никак не обрабатывается и выводится на страницу в исходном виде. Теперь рассмотрим такой пример ввода:

<script type="text/javascript">myRef = window.open('http://www.google.com','mywin',
'left=20,top=20,width=700,height=500,toolbar=1,resizable=0');</script>

Нетрудно видеть, что javascript код исполнится после сабмита формы. Лечится пропусканием ввода через htmlentities() непосредственно перед показом:

echo("You typed this:");
echo(htmlentities($_POST['myText']));

3. Использование HTTPS

Здесь все очень просто. Если ваше приложение работает с финансовыми, медицинскими или просто с очень важными данными - используйте HTTPS. Данные между браузером и веб-сервером передаются в зашифрованном виде и не могут быть расшифрованы в случае перехвата сниффером.

4. Предотвращения скачивания пользовательских файлов по прямой ссылке

Рассмотрим веб-приложение, где пользователи могут закачивать на сервер свои личные файлы. Некоторые файлы могут быть конфиденциальными и не должны быть доступны никому, кроме их владельца.

Есть закачивать все файлы в директорию вида public_html/files, то файл mysecretdoc.pdf будет доступен любому желающему по прямой ссылке http://mysecurewebsite.com/files/mysecretdoc.pdf.

Есть как минимум два способа предотвратить эту ситуацию:

• вынеcти директорию files на уровень выше, чтобы она была вне корня вебсайта и не была доступна через веб
• использовать .htaccess для запрета прямого скачивания

5. Пароли пользователей

- Не хранить пароли открытым текстом

Достаточно очевидное решение. Если мы будем хранить хэши паролей (MD5+salt), последстивия утечки таблицы паролей становятся намного менее серьезными, особенно в сочетании со следующим пунктом.

- Требовать, чтобы пароли удовлетворяли определенными правилам сложности и заставлять менять их через какое-то время. Как пользователь я не очень люблю этот метод, но он работает.

- Использовать комбинацию пароля (пин-кода) и устройства типа RSA токена для логина. Подойдет для банковских или внутрикорпоративных приложений.

- Сделать авторизацию через сторонний сервис, такой как Facebook, Twitter или OpenID. Пусть у них болит голова как уберечь пароли.

6. Шифрование и обфускация кода

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

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

Шифрование кода для PHP: ionCube, ZendGuard, SourceGuardian

Обфускация: Thicket Obfuscator for PHP

7. Шифрование данных

Шифрование данных защищает от ситуации, когда база данных попала в чужие руки, но нет кода, который с ней работает.

Технически ничего сложного здесь нет. Шифрование/декодирование можно реализвать как средствами языка программирования так и в самой БД. Второй метод предпочтительнее, особенно если нужно реализовать поиск по зашифрованным данным.

Вот как это можно сделать для MySQL.

Шифрование с помощью триггеров

delimiter |
 
CREATE TRIGGER insert_encrypt BEFORE INSERT ON cars
  FOR EACH ROW BEGIN
    SET NEW.Model = AES_ENCRYPT(NEW.Model,"my passphrase");
  END;
|
 
delimiter |
 
CREATE TRIGGER update_encrypt BEFORE UPDATE ON cars
  FOR EACH ROW BEGIN
    SET NEW.Model = AES_ENCRYPT(NEW.Model,"my passphrase");
  END;
|

Декодирование в SQL запросе

SELECT
...
AES_DECRYPT(Model,"my passphrase"),
...
FROM carscars

Бонус для параноиков

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

Из минусов:
- при смене пароля придется перешифровать данные
- в случае утери пароля восстановить данные не получится

8. Защита данных сессии (PHP, shared server)

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

Содержание типичного файла сессии PHP:

userName|s:5:"admin";accountNumber|s:9:"123456789";

Решение:
- шифровать переменные сессии
- хранить данные сессии в БД. В PHP можно переопределить обработчик сессии с помощью функции session_set_save_handler

9. Отключите показ сообщений об ошибках

Как только система переводится в режим продакшен убедитесь что никакие необработанные сообщения об ошибках не будут показаны пользователю. Это может дать информацию о структуре базе данных или о структуре приложения.

Как минимум, сообщения об ошибках стоит отключить. В PHP это можно сделать вот так:

error_reporting(0);
@ini_set('display_errors', 0);

Наиболее же правильный метод это перехват сообщений об ошибке, запись их в БД, отправка уведомления разработчику итд. В PHP перехват сообщений об шибках делается с помощью функции set_error_handler(). И вот еще пример перехвата фатальных ошибок, которые нельзя перехватить с помощью set_error_handler().

10. Защитите соединение между базой данных и приложением

Применимо к ситуации когда база данных расположена на другом сервере. Вот статья, которая рассказывает как создать SSL тоннель между MySQL и PHP.

11. Защита от form spoofing

Допустим у вас есть форма редактирования данных пользователя вот с таким УРЛ: http://example.com/edit_user.php?id=12345. Ничто не мешает пользователю 12345 поменять номер аккаунта в УРЛ и попытаться отредактировать другого пользователя. Простая проверка на стороне сервера пресекает эти попытки на корню.

Неискушенный прграммист может подумать, что заменив GET на POST мы избавимся от номеров аккаунтов в УРЛ и закроем уязвимость. Разумеется это не так. Сохранив страницу на свой компьютер и изменив данные формы, злоумышленник может подделать POST запрос.

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

Эта тема плотно перекликается с валидацией всех данных, вводимых пользователем. Допустим у вас есть радио-кнопка с выбором пола.

 
<input name="gender" type="radio" value="m" />Male
<input name="gender" type="radio" value="f" />Female

Зная, что значение этого поля может быть только m или f, программист может посчитать проверку этого поля необязательным и записать его в базу данных в виде как оно есть.

Злоумышленник может сохранить эту страницу себе на диск и поменять ее следующим образом.

 
<input name="gender" type="text" value="m';DROP TABLE `Users`; ... " />

Даже если вы обработаете ввод с помощью mysql_real_escape_string(), значение все равно получится слишком длинным для односимвольного поля и поломает запрос (вот для чего мы советуем отключать сообщения об ошибках в продакшен версии).

Хорошим решением будет усечение этого поля до одного символа:

substr($_POST['gender'],0,1)

12. Cross-site request forgery (CSRF)

Эта уязвимость менее известна чем XSS, хотя не менее опасна. Представим себе форум, где участник Vasya постит сообщние, содержащее вот такой вот код:

<img src="http://mysecurebank.com/withdraw?account=petya&amp;amount=1000000&amp;for=vasya" />

Когда эту страницу откроет участник Petya, браузер исполнит запрос

http://mysecurebank.com/withdraw?account=petya&amount=1000000&for=vasya

Проблема в том, что если банк хранит данные доступа в куках, Petya будет залогинен автоматически и транзакция совершится от его имени, о чем он, конечно, и не подозревает.

Первая мысль которая приходит в голову - заметить GET на POST на всех важных формах (или вообще на всех). К сожалению это не решает проблему полностью. Ничто не мешает злоумышленнику разместить вот такую форму на своем вебсайте:

 
<form id="f" action="http://mysecurebank.com/withdraw" method="post">
<input name="account" value="petya" />
<input name="amount" value="1000000" />
<input name="for" value="vasya" />
    </form>
 

Если Васе удастся заманить Петю на свой вебсайт - форма будет отправлена и цель достигнута. Еще одна причина не ходить по подозрительным вебсайтам.

Как с этим бороться?

• проверять значение HTTP реферера. Должно быть всегда с вашего собственного вебсайта. К сожалению положиться на это дело полностбю нельзя, так как многие прокси сервера могут его не передавать. К тому же его не так сложно подделать.
• использовать скрытое поле в форме с секретным значением, как правило привязанным к сессии пользователя. Злоумышленник не может прочитать форму от имени Пети, поэтому секретное значение окажется для него неизвестным (XmlHttpRequest не может выполнить запрос к другому серверу).
• Дополнительно отправлять куки через форму (прочитать с помощью джаваскрипта и вставить в форму). Если куки переданные через форму не совпадают с куками из заголовка - транзакцию не проводить.
• Ограничение времени жизни кук

Дополнительная информация:
http://en.wikipedia.org/wiki/Cross-site_request_forgery
http://www.codinghorror.com/blog/2008/09/cross-site-request-forgeries-and-you.html

Заключение

Теперь хорошие новости. От большинства этих уязвимостей несложно защититься. Многие PHP фреймворки (Yii, CakePHP, CodeIgniter, Zend, Symfony) и генераторы кода (PHPRunner) имеют встроенную защиту от большиства уязвимостей. Тем не менее, стоит понимать, как оно работает, чем чревато и как защититься. Предупрежден - значит вооружен.

Сокращенный перевод статьи Марка Хедлунда, основателя Wesabe. Оригинал здесь.

Оба вебсайта предоставляли сервис управления персональными финансами. Были запущены примерно в одно и то же время (2006-2007 год). Mint был куплен Intuit в сентябре 2009 года за 170 миллионов долларов. Wesabe закрылся в июне 2010 года.

Почему так произошло? Дальше от лица Марка Хедлунда.

--------------------------------------------

Прежде всего развеем несколько мифов.

1. Mint победил, потому что был запущен раньше

Неверно. Wesabe был запущен на 10 месяцев раньше. Можно говорить о том, что мы поспешили выйти на рынок, когда продукт еще не был полностью готов. Можно сказать. что Mint и другие могли спокойно учиться на наших ошибках, пока мы набивали шишки.

2. Wesabe никогда не зарабатывал денег

Неверно. Wesabe начал приносить доход в конце 2008 года, за полтора года до того как мы закрылись. К слову, деньги инвесторов закончились на 9 месяцев раньше, чем мы закрылись т.е. последние 9 месяцев мы зарабатывали достаточно, чтобы покрывать текущие расходы. К сожалению этих денег не хватило, чтобы продолжать развитие.

3. У Mint было лучше название и лучше дизайн

И то и другое верно, но врядли послужило основной причиной нашего поражения. Рынок показывает множество примеров самых разнообразно звучащих брэндов, которые сумели победить своих конкурентов. Дизайн тоже важен, но не может служить единственной или главной причиной победы на рынке.

4. Wesabe не был "вирусным", а Mint был

Наполовину верно. По-большому счету ни тот ни другой продукт не был вирусным. Mint в основном приобретал новых пользователей посредством Google Adwords (есть цифры, что привлечение каждого нового пользователя обходился им в 1 доллар). На графике видно, что трафик перестал расти сразу после их приобретения в сентябре 2009 и не рос 6 месяцев. Очевидно, что рост связан с размерами маркетингового бюджета, а не с вирусным распространением.

Кликабельно.

Хорошо, почему же тогда Mint добился такого успеха, а Wesabe нет? Я вижу две основные причины.

Во-первых, мы решили не работать с Yodlee, но не смогл найти им подходящую замену. Yodlee это агрегетор финансовых данных, предоставляющий доступ к ним в виде веб сервиса. Когда мы общались с ними в 2006 году, Yodlee была не в лушем состоянии после неудачной попытки продаться и потери несколько ведущих специалистов. К тому же они вели переговоры очень агрессивно, предлагая первые 6 месяцев бесплатно, после чего они назовут свою цену. Мы не решились вести бизнес с комапнией, находящейся в таком состоянии.

Mint же не побоялся и использовал Yodlee для получения пользовательских данных напрямую с банковских сайтов (Yodlee разработал парсер для каждого отдельного банка). Это дало возможность предоставить клиентам более понятный и удобный сервис. Wesabe решил построить свою собственную систему получения данных из банков, но это заняло время и они сумели сделать похожую функциональность только через 6 месяцев после того, как она появилась и Mint.

Наша ошибка была не в том, что мы начали делать свою систему получения пользовательских данных из банков. Ошибка была в том, что мы не сделали ее достаточно быстро и не использовали Yodlee в тот период, пока наша система не была готова.

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

Я считаю, что любой сервис, работающий в области персональных финансов, должен делать две вещи. Певрое - сделать пользователя счастливым. Второе - помочь ему улучшить свою финансовую ситуацию. Mint перуспел в первом, в то время как во втором ни Mint, ни Wesabe не добились успеха. Да, Mint многократно заявлял, что из пользователи улучшили свое финансовое положение, но, поскольку дело происходило во время кризиса, другие люди тоже стали меньше тратить и уменьшили свои долги. Цифры уменьшения долгов и увеличения накоплений, предоставленные Mint совпали со средними по странам, в которых он работает.

Да, именно так. Менять поведение людей очень тяжело и еще никто на этом рынке не добился успеха в этом плане. Последнее слово на рынке управления персональными финансами еще не сказано.

Может у 4х конвертов это получится?

New York Times опубликовал отличную статью, от том как ведет онлайн-бизнес наш соотечественник Виталй Боркель, проживающий в Бруклине. Если очень коротко - Виталий использует крайне грубые методы обращения с клиентами, что приводит к массе отрицательных отзывов о нем на других вебсайтах. По словам Виталия эти отрицательные отзывы помогают ему держать хорошие позиции по ключевым запросам. Он продает дизайнерские очки и по таким запросам как designer eyewear lafont его вебсайт (DecorMyEyes) находится на первых позициях.

Читать на английском или сокращенный перевод на русском. Вот еще интересное обсуждение на Hacker News, где Matt Cutts (глава команды, работающей над качеством поиска в Гугл) рекомендует сайтам, на которых оставляют отзывы, добавлять rel=nofollow к отрицательным отзывам, чтобы они не помогали продвижению в поиске.

Мне кажется, с этой задачей Гугл мог бы справляться самостоятельно, показывая рейтинг продавца для "покупательных" запросов. Тем более что для тех продавцов, что зарегистрированы в  Google Products он и так это делает. Для всех остальных он мог бы брать данные с сайтов типа BizRate или Better Business Bureau.

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

-----------------------------------

Другие интересности

140 советов интернет-журналисту от Александра Амзина

140 вопросов из гугловских интервью. Мой любимый конечно же "How much should you charge to wash all the windows in Seattle?" и вот почему.

Патрик МакКензи делится своими заметками с Business of Software конференции, проходившей в этом году в Бостоне. Выдержка из выступления Dharmesh Shah.

Рассмотрим какое-нибудь типичное веб-приложение с помесячной оплатой. Владельца больше всего интересуют две цифры: сколько новых клиентов приходит каждый месяц и сколько старых уходит (churn rate). Для примера: допустим есть тысяча клиентов, каждый месяц приходит 100 новых и уходит 50 старых (churn rate 5%). Если прибыль от новых клиентов превышает затраты на их привлечение - вы в шоколаде.

Поговорим о том, как работать над уменьшением второй цифры. Следует отметить, что низкий churn rate еще не говорит о том, что клиент счастлив. Возможно он собирается уйти, как только закончится его контракт или найдется альтернатива. Чтобы оценивать, насколько клиент удовлетворен сервисом, Dharmesh вводит термин Индекс Счастья Клиента (ИСК).

Вычисление ИСК использует три основных фактора:

1. Частота пользования приложением. Чаще пользуется - меньше вероятность, что уйдет.
2. Как много разных фич использует.
3. Использование продвинутых фич (тех, которые реализованы значительно лучше, чем у конкурентов или сосвсем отсутствуют у последних).

Тут все понятно. Скажем есть человек использует Microsoft Word, чтобы просто набирать текст, он может пересесть на любой другой редактор в течение двух минут. Если он использует сложное форматирование - переход будет посложнее. Если он использует макросы и VBA - переход вообще становится нереален.

Теперь вы можете вычислить ИСК для каждого клиента (а в веб-приложении это сделать очень легко) и работать над его повышением.

• звонить/писать клиентам с низким ИСК, предлагая помощь
• оценивать работу тех.проддержки и продажников по уровню повышения ИСК
• оценивать новые фичи по уровню изменения ИСК (через A/B тестирование)

Dharmesh также сказал, что его компания продает консалтинговые услуги, помогая новым клиентам настраивать их аккаунты. Несмотря на то, что эти услуги приносят в копилку всего 7% дохода и имеют невысокую маржу, они повышают ИСК и тем самым увеличивают продажи основного продукта.

Резонный вопрос - если консультации приводят к такому повышению продаж, почему бы не предоставлять их бесплатно? Ответ: люди больше ценят то, за что они заплатили. Когда ты предоставляешь 5 часов бесплатного консультирования по телефону, клиентам - являющимся успешными предпринимателями - им не так просто найти 5 часов в своем расписании. А вот если брать с них 500 долларов за такую консультацию, можете быть уверены, они найдут время. Это интересная мысль, скорее всего такой подход лучше всего работает, если ваши клиенты - владельцы бизнеса, чье время стоит дорого.

Купил себе Kindle. Одна читалка в семье уже есть, но официально это подарок жене, а по мере роста детей все чаще возникают ситуации, когда почитать хочется обоим одновременно.

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

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

Форматы fb2 и epub не поддерживаются, но есть такой замечательный сайт, как 2EPUB, который сконвертит вам что угодно во что угодно. К слову, он и из PDF может сделать .mobi, но часть форматирования может потеряться.

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

Помимо просто удобства это добавляет несколько интересных вариантов использования. Скажем можно подарить Kindle родителям и закачивать им новые книги на устройство без их вмешательства. Можно сделать кнопку в браузере вида 'Read in Kindle', которая сконвертит статью в нужный формат и перешлет ее вам на устройство.

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

Habrahabr: Разработчики софта, давайте зарабатывать больше!

Techcrunch: NSFW: Generation Whine – Why I’m Relieved not to be a Millennial

Zadolba!li: Активисты голосисты

Читаю Генри Форда "Моя жизнь, мои достижения". Несмотря на то, что книга была написана в 1922, а события описываются еще более ранние, обилие параллелей с днем сегодняшним потрясает.

Вот что говорит Форд о отношении к работе:

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

И о финансировании предприятий:

Деловые люди думали тогда, что можно сделать с предприятием все, если его «финансировать». Если с первого раза это не удалось, рецепт гласил: «финансировать снова». Так называемое «новое финансирование» состояло в том, что бросали верные деньги вслед за сомнительными. В большинстве случаев новое финансирование вызывается дурным ведением дела; следствием его является то, что оплачивают дурных руководителей для того, чтобы они еще некоторое время продолжали свое дурное хозяйничанье. Судный день этим только откладывается: новое финансирование есть уловка, выдуманная спекулянтами. Все их деньги ни к чему, если они не могут поместить их там, где действительно работают, а удается им поместить лишь там, где организация дела страдает какими-нибудь недостатками. Спекулянты воображают, что они с пользой помещают свои деньги. Это заблуждение – они расточают их.

Дети в возрасте 2-4 лет активно шалят, наблюдая при этом за реакцией родителей. Так они узнают, что можно и что нельзя, проверяют границы дозволенного. Психологи считают лучшей стратегией мягко, но настойчиво объяснить ребенку, что его поведение неверно. Здесь важно не переборщить с противостоянием, чтобы не вызывать ответную агрессию.

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

Пример из жизни

У нас есть три уровня поддержки: никакой - бесплатно, простой - дешевый, сложный - почасово, дорого. Обращается с вопросом клиент, у которого на данный момент никакой поддержки нет. Вопрос не самый простой, требует написания кода.

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

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

Ошибка очевидна. Хочешь сделать исключение из правил - объясни, что это разовая поблажка, скидка по поводу выхода новой версии (дня программиста, солнечного затмения или месячника борьбы с каннибализмом).

Где провести границу

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

Но это у программистов так, а менее подкованные клиенты могут всерьез считать, что купленный ими молоток резво пробежится по всему дому забивая гвозди и развешивая полки. К нам многократно обращались клиенты с  просьбами помочь в вопросах, не имеющих никакого отношения к нашему софту. Один друг пишет: " я тут нашел в интернете кусок кода, а он не работает, помогите". На вопрос, а почему, собственно, он это у нас спрашивает так и ответил: "Ну я думал, а вдруг вы знаете". Нет, это не ребенок трех лет, это ведущий програмист  в немаленьком университете.

Итак, необходимость правил очевидна. Сразу возникает вопрос - насколько жесткими должны быть эти границы. Если снова обратиться к терминологии британских ученых детских психологов, то у нас есть такие варианты: вседозволенность, демократия и авторитарность.

Выбор непрост. Более того, он может быть определяющим фактором успеха для бизнеса.

Мы готовы разбиться в лепешку, лишь бы клиент был счастлив (вседозволенность)

В каких случаях это может сработать:

1. Клиент платит достаточную сумму денег, которая покрывает любые (разумные) капризы. По такому пути, например, идет хостинговая компания Rackspace со слоганом Fanatical support. Аренда сервера будет стоить у них в два раза дороже среднего по планете, но их клиентов это не останавливает.

2. Продукт или сервис достаточно прост, поддержки почти не требуется.

3. Наличие доступа к недорогой рабочей силе (аутсоурсинг поддержки в теплые страны).

Демократия и авторитарность

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

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

Какой путь выбрать для своего бизнеса - решать вам. И если вы все еще верите детским психологам, наиболее приспособленные к жизни дети вырастают у авторитарных родителей (Элиум Дон, Элиум Джоан. «Воспитание сына».СПб.,1996.).

Май 1981 года.

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

Билл добавил новый код к QuickDraw (который в то время все еще назывался LisaGraf), который рисовал окружности и овалы потрясающе быстро. Это не так просто было сделать на Макинтоше, поскольку это требует извлечение большого количества квадратных корней, в то время как 68000 процессор в Lisa и Macinthosh не поддерживал операции с плавающей запятой. Но Биллу удалось найти очень изящное решение, которое использовало только сложение и вычитание. Ему удалось обойтись даже без умножения и деления, что 68000 конечно умел, но делал это не очень быстро.

Его решение строилось на том факте, что сумма последовательных нечетных всегда является квадратом целого числа (например, 1 + 3 = 4, 1 + 3 + 5 = 9, 1 + 3 + 5 + 7 = 16, итд). Таким образом он мог вычислить когда в цикле нужно было увеличить соотвествующую координату. Это позволило QuickDraw рисовать овалы очень быстро.

Билл запустил демо и быстро заполнил экран Lisa овалами разной величины, быстрее чем кто-либо мог себе представить. Однако что-то беспокоило Стива Джобса. "Ладно, окружности и овалы это здорово, но как насчет прямоугольников со скругленными углами? Мы можем сделать это тоже?"

"Нет, это невозможно. Более того, я не думаю, что это вообще нам может когда либо понадобиться". Я думаю, что Билл был слегка растроен, что Стив не был в восторге от его новых алгоритмов и хотел чего-то еще.

Стив внезапно вошел в раж. "Скругленные прямоугольники окружают нас повсюду. Ты только посмотри вокруг себя." Действительно, он был прав, кругом было полно таких предметов. Затем он показал на улицу. "Посмотри снаружи, там их еще больше, они со всех сторон". Он потащил Билла на улицу и они сделали круг вокруг здания. Стив показывал на каждый скругленный прямоугольник, который встречался им на пути.

Наконец Стив и Билл подошли к знаку "No parking", который тоже обладал скругленными углами. "Ладно, я сдаюсь", сказал Билл. "Я посмотрю, что можно сделать". Он пошел домой и продолжил работу.

Билл вернулся в Texaco Towers на следующий день с большой улыбкой на лице. Он показал демку, которая рисовала прямоугольники с замечательно скругленными углами и делала это потрясающе быстро. Он добавил этот код в LisaGraf, назвав этот примитив "RoundRects". Через несколько месяцев скругленные прямоугольники проникли во все элементы пользовательского интерфейса и стали незаменимы.

Оригинал на английском вот здесь.

--------------------------------------

От себя добавлю. Прошло почти 30 лет. Microsoft вот-вот добавит поддержку отрисовки скругленных прямоугольников средствами CSS в Internet Explorer 9.