Архив рубрики 'стартап'

HIERARCHICAL TODO-LIST DIRECTLY IN THE MESSENGER

Понедельник, Февраль 27, 2012

If you are using the IM-client for Jabber (GTalk, Miranda, Kopete, QIP, etc.),
you can create and manage the TODO-lists directly from the chat window.

To create a list add any_name@bot.jodo.im in your contact list.

To add a task to the list write to this user:

+ name of task
[description of the task]

The square brackets indicate optional.

In response, we obtain:

Task 1 is created.

Where 1 – is the number of this task.

To create subtask:

+number subtask_name
[description of the subtask]

Listing all tasks:

#tree

Mark task completed:

#ok number [comment]

Other commands can be found by typing #help

You can create any number of such lists for each area of life.
Jabber-clients there for all platforms.

Thus we are able to quickly work with your ToDo directly from the chat window.

Service is free and has a web interface is available on http://jodo.im/ after registration with command:

#register your_login your_password your_email

If you do not have an account on any jabber-server, then you can get it on the same server after web-registration http://jodo.im/registration/

ИЕРАРХИЧЕСКИЕ TODO-СПИСКИ ПРЯМО В ОКНЕ МЕССЕНДЖЕРА

Воскресенье, Февраль 26, 2012

Если вы используете IM-клиент с поддержкой Jabber (QIP, Miranda, GTalk, Kopete и т.п.), то вы можете создавать и управлять TODO-списки прямо из окна чата.

Для создания списка нужно добавить себе в контакты любое_имя@bot.jodo.im.

Для того, чтобы в список добавить задачу пишем этому пользователю:

+ название
описание задачи

В ответ получаем:

Задача 1 создана.

Для создания подзадачи пишем

+номер текст_подзадачи

Для принятия

#ok номер необязательный_коммент

Другие команды можно узнать введя #help

Можно создать сколько угодно таких списков для каждой области жизни.
Jabber-клиенты есть для всех платформ.

Таким образом мы получаем возможность очень быстро работать со своими ToDo прямо из окна чата.

Сервис бесплатный.

Если у вас нет аккаунта ни на каком jabber-сервере, то его можно получить на том же сервере, где работают боты, пройдя регистрацию
http://jodo.im/registration/

Подробнее о ботах
http://jodo.im/help/Bots

Мой новый проект: JoDo.im – управляй фрилансерами он-лайн.

Воскресенье, Февраль 19, 2012

imageЭтот сервис создавался в первую очередь потому что был нужен мне самому. C 2002 года я занимаюсь веб-разработками с привлечением фрилансеров.

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда я спрашивал удалённого программиста: “Какие у тебя остались задачи?”, то дальше следовала в лучшем случае пятиминутная пауза, когда он рылся в своих записях, логах, перед тем как сформулировать ответ. И тот бывал, как правило, не точным. Программист имел доступ к нескольким десяткам репозиториев, и получал множество мелких пожеланий по проектам каждый день.

Из 10 пожеланий 5 делалось, 3 делалось, но не так, а 2 забывалось. И фрилансер с чистой совестью говорил” “Всё сделал!”.

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

В итоге мне пришла идея полезной (для целей работы с фрилансерами) системы мгновенных сообщений.

1. Она должна распознавать, когда в тексте идёт задача и запоминать её.
2. У задач могут быть подзадачи
3. Фрилансер физически не должен иметь возможность сообщить о выполнении задачи, если есть невыполненные подзадачи.
4. Заказчик должен в любой момент видеть список задач фрилансера и список присланных задач для проверки
5. У задач можно менять статусы: принимать, отменять, закрывать, замораживать, открывать заново.

Что получилось?

Был создан свой jabber-сервер JoDo.im (что можно расшифровать как Jabber ToDo или Job To Do).

Заказчик регистрируется через сайт и заводит новый аккаунт в свой jabber-клиент. Фрилансер может быть зарегистрирован на любом jabber-сервере.

Когда фрилансеру посылается задача, то она предваряется знаком плюса и пробелом.

Например:

+ Убрать Fatal Error с такой-то страницы
Этот баг возникает если мы нажмём….

В ответ заказчик получает:

Создана задача 1.

А фрилансер видит:

Новая задача 1
Убрать Fatal Error с такой-то страницы
Этот баг возникает если мы нажмём….

Чтобы создать подзадачу достаточно написать:

+1 Забыл сообщить детали…

Число допустимых уровней вложенности пока практически не ограничено.

Сервис заносит задачи в базу данных и потом список задач можно посмотреть через личный кабинет сайта, или прямо в окне чата, послав команду #tree фрилансеру.

Ваше дерево задач:
1. Убрать Fatal Error с такой-то страницы (Открыта)
?1.1. Забыл сообщить детали… (Открыта)

Также задачи можно создавать через сайт – в таком случае к ним можно прикреплять файлы.

Фрилансер, чтобы отправить задачу на проверку пишет:

#done 1 Необязательный комментарий фрилансера

Заказчик получает сообщение:

Проверьте задачу 1
“Убрать Fatal Error с такой-то страницы”

Принимает заказчик задачу так:

#ok 1 Необязательный комментарий заказчика

У задач можно менять приоритеты с помощью команд: #top, #up, #bottom, #down.

Остальные команды можно посмотреть с помощью команды #help или раздела помощи на сайте.

Обычное общение – идёт как обычно. Таким образом в потоке обсуждения с минимальнейшими усилиями мы приобретаем возможности системы управления задачами.

Чтобы работа не встала в случае каких-либо проблем с jabber-сервером по-умолчанию включён дубляж всех задач и изменений статусов на емейл как заказчику, так и исполнителю.

Для упорядочивая собственных дел можно насоздавать виртуальных исполнителей (ботов) для себя любимого. Достаточно добавить контакт любое_имя@bot.jodo.im в свой список контактов. При этом вам даже не нужно регистрироваться.

Система бесплатная. И в будущем тоже всегда будет возможность работать с ней бесплатно. Планируемая монетизация – тарифные планы с дополнительными возможностями.

Итоги внедрения.

Фрилансеры быстро врубаются в механизм работы системы – ведь по сути кроме умения использовать мгновенные сообщения и знать пару команд ничего не нужно. В заявках на фриланс-биржах я писал “Знание Jabber обязательно”. Люди находились без проблем.

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

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

Мобильность – мой собственный основной заказчик работает со мной с мобильного телефона. Я сам часто ставлю задачи с кпк, когда не спится. Jabber-клиенты есть для всех платформ.

Попробуем?

Управление фрилансерами: Начало

Вторник, Ноябрь 1, 2011

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Восстановление данных – RAID5, ReiserFS

Суббота, Март 13, 2010

В прошлый четверг произошло супермаловероятное событие – полетел рейд5 из 4-х винтов. Перестал переходить в состояние optimal. В онлайн и в "force online" также не переходил.

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

Вероятность такого события 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

Пробую Блогун

Понедельник, Март 23, 2009

Напомню, что мой проект askfor.info является местом, где встречаются гуру (эксперты) и вопрошающие. Последние имеют возможность за деньги узнать ответы на свои вопросы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исторический момент – мой стартап!

Вторник, Декабрь 23, 2008

Доброго времени суток, люди! Я рад представить свой стартап над которым я работал последние 1,5 года.
Пожалуйста, оставляйте свои комментарии и отзывы – это очень важно для меня!

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

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

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

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

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

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

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

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

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

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

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

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

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

Индийские PHP-программисты дешевле в 2 раза

Вторник, Февраль 19, 2008

Зарплаты русских php-кодеров сейчас достаточно высоки. Так ли дело обстоит в других странах?

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

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

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

Распределение зарплат по данным с hh.ru

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

 Распределение зарплат индийских программистов

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

Россия Индия
10000 5208
15000 7813
20000 10417
25000 13021
30000 15625
35000 18229
40000 20833
45000 23438
50000 26042
55000 28646
60000 31250

Как легко видеть индусы готовы работать за суммы в 2 раза меньшие. Часовая разница с Москвой +2,5 часа – вполне терпимо.

Исследованные сайты:

http://naukri.com/ (самый большой. Разместить одну вакансию стоит от 35 долларов)
http://monsterindia.com/ (Одна вакансия – 1200 рублей)

Запрос Гугла показывающий индийские сайты по трудоустройству

Исследование (OpenOffice calc)

Стартап и патенты. Вакансия

Четверг, Февраль 14, 2008

Сегодня речь пойдёт о патентовании гениальных идей и и вакансии 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

Кешировать данные в файлах

Понедельник, Ноябрь 5, 2007

Этот пост только для PHP-программеров. Остальным он будет непонятен.

В 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

Число элементов Время ReiserFS 3.6 (опции BORDER, SMALL_TAILS), секунды MySql 4.1, секунды
1000 real 0.112 0,16
user 0.084 0,11
system 0.028 0,02
100000 real 5,75 8,11
user 2,48 2,54
system 3,11 0,96
1000000 real 104 75,87
user 25,67 24
system 62,88 8
1000000 (не дефрагментированный результат) real 96,92 74,78
user 25,89 23,94
system 63,11 8,86

Когда тестировался миллион элементов 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 может выиграть по скорости и при миллионе элементов.