В этом выпуске мы поговорим о том, как управлять ими.

Лирическое отступление как правило я заказываю фрилансеров на сайте weblancer.net. В последнее время сервис стал брать с них комиссию и произошёл некоторый отток на сайт free-lance.ru.

Начинал я с управления по телефону и электронной почты.

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

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

Проблемы с “забыл”, “этого не было сказано”, ” я понял не так” – огромны. В проекте где множество деталей нельзя полагать на такой способ управления.

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

Эти замечания оказываются распылёнными по нескольким десяткам писем и опять что-то забывается, теряется и т.п.

После чего я попробовал систему управления задачами egroupware. Довольно тяжёлая система (в плане нагрузки на сервер). Очень сложно оказалось убеждать фриласеров ей РЕГУЛЯРНО пользоваться. Да, при должной дисциплине, это неплохое решение. Однако дисциплина – это одно из слабейших мест у фрилансеров. Довольно много полей. Нужно прилагать интеллектуальные усилия, чтобы понять как их заполнить. Что отвлекает от самой задачи. Вывод: не прижилась. Система неочевидна и не так проста как хотелось. Фрилансеров напрягает в ней разбираться.

Потом я использовал ICQ. Главнейший минус аськи был в том, что она не хранила историю сообщений на сервере. И приходилось настаивать на том, чтобы фрилансеры включали лог сообщений.

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

Поиск в логах утомителен. На другом компьютере лога аськи не было.

Поэтому следующий шаг был переход на Gtalk. Это сервис Гугла основанный на открытом протоколе Jabber. История сообщений была на серверах Гугла. Искать стало проще. Исчезла привязка к конкретному компьютеру.

Это решение из вышеперечисленных самое лучшее.

Но тем не менее обнаружились различные глюки и в системе Гугла. Что-то что находилось у меня, что-то не находилось у фрилансера. При поиске Гугл выкусывает произвольные фрагменты из переписки, что не так удобно для пересылки фрилансеру.

В некоторых случаях оказалось удобным сделать документ в Google Docs. И дать право на правку фрилансеру. Он зачёркивал то, что было сделано. Со временем такой способ приводит к огромным зачёркнутым массивам строк, в которых нужно искать несделанные доработки. Дискутировать в самом документе также неудобно.

Резюме: на текущий момент Gtalk и Google Docs самые удобные иснструменты для управления фрилансерами.

Интрига: в ноябре я презентую стартап, которые поднимет удобство работы с любыми исполнителями на новую высоту. До новых выпусков!

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

Вероятность такого события 0.0001% в день. То есть примерно 1 раз в 10 лет. Ну чтож бывает.

Но такой геморрой! Такая ЖОПА!

Короче говоря, пришлось за пару дней спать 3 часа. После первого дня я понял, что я попал серьёзно.

Под конец дня осознав серьёзность проблемы и того, что своими силами в серверной её никак не решишь я позвонил в спец. фирму по восстановлению данных. Мне сказали – 4 тысячи за один диск рейда. Цена меня устроила. Работает фирма допоздна. Поехал.

Богатый офис. Сказали, что с ReiserFS мне ничего не восстановят. Стали диагностировать рейд. Пока я ждал результатов экстренной диагностики (2500 р.) мне предложили полистать журнальчики.

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

Я уговорил дать мне поработать в интернете. Читать журнальчики несколько часов -  это тупизна. Смотреть на диагностику нельзя. Большой секрет. Типа частично самописная программа. Но это меня насторожило. Если самописная, то я же её не украду? Что-то нечисто…

В сети нашёл неплохой рецепт восстановления удалённых файлов с ReiserFS.

reiserfsck –rebuild-tree -S -l /root/recovery.log имя_девайса

Мне показалось, что сработает. Но меня удивило, что ведущий специалист этой серьёзной фирмы о нём не знает. Так-так-так…

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

Дома получилось восстановить более половины томов бакапа с ReiserFS (спал 3 часа за ночь). Хорошо. Файлы потеряли свои имена и оказались в папке lost+found. Если бы я на этот диск сдуру бы не записал 3,6гб данных, то восстановил бы 90% томов.

Но всё равно много файлов было утеряно. Клиентам это не понравится. Я решил не запускать на следующий день (пятница) сервак на гнилых данных, а восстановить всё любой ценой. И лучше самому. Охреневшие от жадности чуваки из datarc.ru заломили 116 т.р. за полное восстановление данных. Увидели, что файлов у меня 1,7 миллиона и что много домашних папок пользователей. Цена ОЧЕНЬ зависит от того насколько эти данные нужны клиенту.

Хер вам. После большого торга согласились (Кирилл) на 16 тысяч за частичное восстановление (первоначальная цена, которая звучала по телефону), но тут вмешалось руководство и оно было согласно только на 32 т.р.за неполное восстановление, за образ!

Я решил попробовать сделать эту супероперацию самому. Блин, я же крутой! Не зря ИУ6 в Бауманке заканчивал.

Попросив совета у добрых людей и для их мотивации предложив премию в 500 рублей я получил бесценные идеи. А именно наводку на программу Raid Reconstructor, которая стоит всего 99 баксов.

Купил 2TB диск (с возможностью moneyback, которой я потом воспользовался) для образа рейда (на рейде был всего один логический диск на 1,5 Тб) я запустил Raid Reconstructor на запись образа. За 16 часов был записан образ. Меня распирало от любопыства насколько он будет хорош.

Ё! Образ оказался идеальным!

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

Полностью восстановила мои данные!

P.S. Вот ещё программки, которые мне приглянулись, но я ими не успел воспользоваться:

Raid Recovery Software

UFS Explorer Professional Recovery

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

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

Я тестирую различные способы рекламы своего проекта.

Первое что я попробовал — это Блогун.

Этот сервис посредник между блоггерами пишушими на заказ и рекламодателями.

Субъективное впечатление: полный отстой. Огромное количество говноблогов, которые созданы только для того, чтобы размещать в них платные посты.

Как правило один блоггер ведёт много говноблогов.

Даже, если вы закажете рекламу в блоге с хорошим ТИЦ и читаемостью (хотя никто не гарантирует, что это живые читатели, а не боты), то в 70% случаев хозяева разместят заказной пост датой месячной давности и его никто не прочтёт.

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

Я не пробовал давать действительно дорогие заказные посты, но с постов стоимостью до 5 долларов включительно толка не было. Правда за одним исключением:

а) блог размещён на домене второго уровня

б) блог ведёт конкретный человек, который ничуть не прячется за никами и аватарками.

После регистрации в Блогуне я получил примерно 150-200 предложений о публикации моего поста. На 99% эти предложения — хлам и шелуха. У так называемых блоггеров есть скрипты, которые в автоматическом порядке шлют вам предложения о публикации где-угодно, но только не по вашей тематике.

Плюс сервиса — есть кнопка «Переделать». Если блоггер схалтурил, то можно его, заразу, заставить переделать халяву.

Общий вывод: стоимость контакта через Блогун довольно дорога. Сам процесс заказа рекламы в блогах трудоёмок. Возможно имеет смысл рекламировать очень дорогие товары, но только на таких блогах откуда начинающие блоггеры копипастют информацию. ТиЦ от рекламной компании в Блогуне пока не поднялся.

AskFor.Info – новый стартап для общения с людьми, ценящими своё время: высококвалифицированными экспертами, знаменитостями, бизнесменами.

Суть проекта
В рамках проекта есть 3 роли: гуру (эксперт), вопрошающий, партнёр. Вопрошающие отправляют сообщения гуру. Чтобы отправить сообщение нужно заплатить получателю. Понятно, что такой логикой будут пользоваться те, кто нуждается в общении с именно этим гуру. И в этом суть проекта, отличающая его от бесплатных сервисов вопросов-ответов. Не каждый эксперт/звезда готов тратить время бесплатно отвечая на вопросы.

Если гуру уже не нужны деньги, то он может использовать сервис в PR-целях, настроив вывод денег на счёт любого благотворительного фонда.

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

С сервисом AskFor.Info всё проще – если сообщение пришло, то за него уже заплачено и нужно только его прочитать и/или ответить.

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

Около гуру, подлинность личности которых подтверждена сервисом, висит соответствующий значок показанный справа.

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

Свой счёт вопрошающий может пополнить через webmoney, СМС, терминалы, Яндекс-Деньги и другие электронные валюты.

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

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

Потенциал
Движок полностью мультиязычен и мультивалютен, данные в БД хранятся в UTF-8. В планах захват капиталлистического мира после отточки технологий на российском рынке

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

Исследовал несколько индийских сайтов на предмет зарплат PHP-программистов.

Исследование весьма приблизительное. Я брал количество вакансий за последние 30 дней, которые помечены ключевым словом “PHP” и предполагают fulltime-работу.

Таблица распределения зарплат php-программистов (по данным из hh.ru)

Таблица распределения зарплат индийских программистов (По данным monsterindia.com)

Вот итоговая таблица соответствия зарплат php-программистов:

Как пример он мне привёл свою фирму, которая выпускает товар под брэндом, который был ещё выдуман в СССР. Я не буду называть его, изменю имя. Например, “Беруши”. Некая зловредная фирма взяла и запатентовала это название. И стала требовать со всех производителей бакшиш.

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

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

Вопреки распостранённому мнению в России идеи патентовать можно. В этом можно убедиться, изучив патенты Microsoft.

Вот ссылка на русскоязычные патенты:
http://www.fips.ru/russite
За умеренную плату (около 1000 рублей) можно получить доступ к полнотекстовому поиску.

Если проект планировать интернациональным, то может быть стоит поискать и в американских патентах. Тем более что доступен без всякой дополнительной платы полнотекстовый просмотр (это камень в огород fips.ru)
http://www.google.com/patents/
http://www.uspto.gov/patft/index.html

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

Видимо после доделки прототипа мне понадобится патентный поверенный. Если есть таковой из читателей – пишите, обсудим.

ВАКАНСИЯ

Нужен на удалённую работу PHP-программист.
Подробнее: http://www.inetstar.ru/developer.html

В ObjectNuke используется схема дискового кеширования некоторых SQL-запросов. Я решил проверить эффективность этой схемы на различных масштабах.

Дело в том, что все проекты нашей фирмы работают на ReiserFS, которая сама по сути является БД с индексированием доступа к файлам. Поэтому у меня и встал вопрос: что эффективнее: один запрос к MySQL или одно считывание файла под ReiserFS?

Итак, я создал таблицу:

CREATE TABLE `skorost` (
`guid` bigint(20) unsigned NOT NULL default ‘0′,
`datatext` char(255) NOT NULL default ”,
`minitext` char(255) NOT NULL default ”,
`date` datetime NOT NULL default ‘0000-00-00 00:00:00′,
`size` bigint(20) unsigned NOT NULL default ‘1′,
PRIMARY KEY (`guid`)
) ENGINE=MyISAM DEFAULT CHARSET=cp1251

Потом заполнил её и дисковый кэш вот этим скриптом:

chdir(dirname(realpath($_SERVER['PHP_SELF'])));

require ‘../conf/config.conf’;
require_core(‘Sqlfunc.lib’);

$conn = &getADO();

for ($i=0; $i < 1000000; $i++)
{
$sSql = ‘INSERT INTO answer(guid, datatext, minitext, date) VALUES (‘.$i.’, “‘.$i.’”, “‘.$i.’”, NOW())’;
$conn->Execute($sSql);
if ($i % 10000 ==0) echo $i.”\n”;
dcache::set(‘values’, $i, $sSql);
}

А потом тестировал время исполнения скриптов последовательного считывания всех значений из кэша и из БД (MySQL 4.1).

time ./test_reiser.php
time ./test_sql.php

Когда тестировался миллион элементов MySQL-база данных занимала 535 мегабайт, а индекс около 12 мегабайт. И то и другое помещалось в кэше. По данным df папка с файлами занимала 211 мб. А по данным du папка с файлами занимала 4,3 гб. Вот как эффективно умеет упаковывать маленькие файлы ReiserFS!

Выводы: Даже до тех пор пока число кешируемых элементов относительно велико (до сотни тысяч), имеет смысл использовать дисковое кэширование. Только в сервисах, где речь идёт о миллионах кешируемых элементов, начинает выигрывать MySql, да и то, если кэшируется результат всего одного запроса.

Нужно учесть следующие моменты:

1. Лучше всего дисковое кеширование использовать, когда кешируется результат одного сложного или нескольких простых запросов. Причём кэшировать желательно уже сгенерированные куски HTML. А иначе загрузка CPU может повысится.
2. Для большинства сайтов оно будет эффективно даже для одного запроса, так как у очень редких сайтов число кешируемых элементов более десяти тысяч.
3. Если диск сильно дефрагментирован, то эффективность дискового кеширования снижается примерно на 10%, на скорость работы MySql это практически не влияет. Т.е. имеет смысл выделять отдельный диск или RAM-диск для папки дискового кеша.

Почему же при миллионе элементов MySql опередила ReiserFS? Если присмотреться к таблице то видно, что при 100 000 запросах время, которое ушло у ReiserFS на работу с файлами составило 3,11 секунды, а при 1 миллионе уже 62 секунды. Запросов увеличилось в 10 раз, а время в 20. Очевидно, что собака зарыта здесь. Видимо если в папке от 500 тысяч файлов, то эффективность работы ReiserFS падает.

Т.е. если разбивать кешируемые элементы по разным папкам (пространствам в терминах ObjectNuke), то, наверное, ReiserFS может выиграть по скорости и при миллионе элементов.

Итак, про мой стартап. Всё что описано в теме работает. Из 22-х листов визуальных спецификаций уже полностью сделано 2.

Ощущение такое, что дальше пойдёт быстрее. Сейчас закладываю в код базовые вещи, структуру.

Потом я их отфотографирую и отдам на реализацию. Также сегодня поработал и над воплощением.

“Быстро сказка сказывается, но не скоро дело делается”. Это я к тому, что прототип должен был быть готов к 10 августа. Уже есть нарисованные спецификации на базу данных и продуманы все концептульные моменты движка.

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

Жаль, раньше не догадался там работать!