Достоинства удаленной работы очевидны — меньше ограничений в поиске специалистов с нужной квалификацией, возможность нанимать людей за пределами МКАД, меньше расходов на ведение бизнеса. С другой стороны, есть и проблемы: наиболее значительные — со стороны организации работы. Последние 4 года я работаю тим лидом распределенной группы программистов (3-15 человек в разное время) для зарубежного заказчика, и хочу поделиться с хабрадевелоперами опытом такой работы :-)

Здесь и далее имеется ввиду следующая организация труда:

1. Заказчик (+on-site команда опционально) в офисе где-нибуть в Европе/США.
2. Тим лид распределенной команды — где-то на бескрайних просторах exUSSR.
3. Члены распределенной команды — также где-то на бескрайних просторах exUSSR.

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

Иногда в проекте требуется проверить данные на предмет орфографических ошибок, не полагаясь на познания пользователя по части языков. Тут нам сможет помочь компания Google, с таким их сервисом, как проверка орфографии, используемым в Google Toolbar. Но, к сожалению, Google не предоставляет открытого API для работы с ним.

Итак, краткое описание:
Для того, чтобы проверить текст нам нужно отослать его в POST на https://google.com/tbproxy/spell?lang=ru, где для смены языка следует заменить значение параметра lang на соответствующий по ISO 3166-1 alpha-2. Текст оформляется в XML вида:

<?xml version="1.0" encoding="UTF-8" ?><br/>
<spellrequest textalreadyclipped="0" ignoredups="0" ignoredigits="1" ignoreallcaps="1"><br/>
 <text>Текст для проверки</text><br/>
</spellrequest>

ignoredups — подсветка повторов
ignoredigits — считать цифры ошибками
ignoreallcaps — не проверять слова написанные капсом (подсказал pointum)

Если всё успешно, мы получаем ответ вида

<?xml version="1.0" encoding="UTF-8"?><br><spellresult error="0" clipped="0" charschecked="272"><br> <c o="27" l="13" s="0"></c><br> <c o="73" l="11" s="1">орфографии и орфографии</c><br> <c o="190" l="11" s="1">пользоваться</c><br> <c o="226" l="13" s="0">пред оставляет пред-оставляет</c><br></spellresult>

Атрибуты тега spellresult:
error — произошла ли ошибка
charschecked — количество проверенных символов

В нем идет перечисление допущенных ошибок (теги c), их параметры:
o — начало исходного слова в тексте
l — длина этого слова
s — точность результата

В самом теге c содержатся предполагаемые варианты написания слов, разделенные символом \t.

P.S. Когда этот текст уже был написан, случайно наткнулся на статью в блоге Paul Welter, которая, в принципе, описывает тоже самое…


UPD: Пользователь wayly написал на PHP класс для проверки текста с помощью этого сервиса, скачать можно по ссылке proxysoft.ru/files/spellchecker.zip (зеркало).

UPD2: mezhevikin подсказал ajax-решение с использованием этого сервиса — orangoo.com/labs/?page_id=3

UPD3: Список поддерживаемых языков

_________
Текст подготовлен в ХабраРедакторе
Код подсвечен в Source Code Highlighter

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

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

Поскольку я только начал разбираться с джаббером решил использовать готовую библиотеку для php (так как мой сайт работает на нем).
Итак, на сайте протокола xmpp (jabber) xmpp.org/software/libraries.shtml я скачал баблиотеку xmpphp (она мне понравилось больше всех своей простотой в понимании) и закачал ее на свой хост.

В функцию добавления комментария на сайте я добавил строки:

include ‘XMPPHP/XMPP.php’;
$conn = new XMPPHP_XMPP('джаберовский сервер', 5222, 'логин', 'пароль', 'xmpphp', 'jabber.ru', $printlog=false, $loglevel=XMPPHP_Log::LEVEL_INFO);
try
{
	$conn->connect();
	$conn->processUntil('session_start');
	$conn->presence();
	$conn->message('ваш джаббер', 'текст сообщения');
	$conn->disconnect();
}
catch(XMPPHP_Exception $e)
{
	die($e->getMessage());
}

Где: джабберовский сервер — сервер через который отправляются сообщения (я указал тот же на который и приходят сообщения).
Внимание! Текст сообщения должен быть с кодировке UTF-8.

Вот собственно и все…

P.S. Спасибо за приглашение на хабр! Решил перенести свою статью из песочницы в блог.

Так получилось, что до недавнего времени все мои web-проекты реализовывались на своих собственных серверах. И по этой причине мне ни разу не приходилось иметь дела с хостингом. Но всему приходит конец и в конце 2008 года я вдруг решил, что просто обязан купить себе хостинг и пару доменов.

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

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

UPD: доступна вторая часть статьи

PDF source

Решили мы как то с приятелем, запустить стартап не стартап, а так, сайт для души. Решили — значит будет запущен. Бюджет… А давай не купим ещё по 2 кружки пива, на это и запустим. В общем денег на домен да на виртуальный хостинг на валуехосте. Так люди мы «взрослые», и делать всё привыкли основательно, нам нужна система управления версиями и выкладыванием. Было решено поднять subversion репозиторий с возможностью раздачи доступа к нему нескольким разработчикам с разными логинами на valuehost. Но у нас виртуальный хостинг со всеми его ограничениями, что делать?

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

Тема эта нетривиальна; преимущества и недостатки того или иного способа валидации на первый взгляд не всегда являются явными. Поэтому я решил что упомянуть о них еще раз будет не лишним.

В последнее время, многие редакторы и CMS'ки автоматически проставляют DOCTYPE для документа, что само по себе является прорывом, но к сожалению этого недостаточно, так как зачастую это именно Transitional схема. Начинающие разработчики не уделяют этому должного внимания, а зачастую вобще не подозревают что у них есть выбор.

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

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

Для решения проблемы я использовал два метода.

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

Это происходит потому, что все «специалисты» знают: дизайн — это красивая картинка.

Дизайн лишь на 20% искусство, на 80% — это точная наука. И вы будете удивлены, когда узнаете, из чего на самом деле состоит каждая картинка.

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

Рано или поздно все web-разработчики сталкиваются с ситуацией, когда Internet Explorer становится проблемой, тормозящей разработку проекта. Сайт свёрстан валидно, по стандартам. Нормально отображается в Mozilla, Opera, Safari и других нормальных браузерах. Но. Открываем его в IE. И видим. Как то, что мы подгоняли по пикселям, строго придерживаясь стандартов, размазано по странице. Ладно ещё в IE7 можно более-менее просто подогнать вёрстку (конечно зависит от дизайна), но от IE6 иногда волосы встают дыбом. К счастью, существуют способы, которые позволяют повлиять на ситуацию. Кто-то использует хаки, кто-то — conditional comments. Где-то можно пойти на компромис и упростить задумку дизайнеров, поддерживая пользователей недобраузеров.

Итак, свершилось то, чего так долго ждали некоторые посвященные блоггеры. Я открыл для всех желающих Parasite Eliminator – сервис и плагин для Wordpress, благодаря которым в моих блогах нет ручного спама.

10 ноября 2008 года – это черный день российских блогоспамеров (у зарубежных будет другой черный день, я еще не знаю, когда сделаю международную версию плагина).

Как оно работает

Привет.
Думаю, среди читателей хабра найдется немало тех, кто имеет stand-alone blog на движке wordpress.

Так вот, для вас, дорогие мои, у меня есть две новости, как водится, плохая и хорошая.
Плохая состоит в том, что wordpress — довольно-таки тормознутая штука.
Виноваты в этом в основном криворукие производители тем и, особенно, криворукие производители плагинов. Особенно кривой плагин, на мой вкус, wp-ajax-edit-comments, который является образцом быдлокодинга.

Хорошая — в том, что это можно поправить.

На конференции Linux Plumbers Conference двое хакеров Арьян ван де Вен (Arjan van de Ven) и Оук Кок (Auke Kok) провели демонстрацию сразу двух систем Linux, каждая из которых загружалась быстрее пяти секунд. В первом варианте использовался модифицированный вариант дистрибутива Fedora, а во втором — модифицированный Moblin. В обоих случаях хакеры оптимизировали работу ядра (по вышеуказанной ссылке, а также в этом интервью можно узнать все подробности, что они сделали).

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

Асинхронная инициализация железа позволила ускорить загрузку ядра до 1,02 с (на ядре 2.6.28 они уменьшат время до 0,5 с). Дальше загрузка шла параллельными потоками.

Как уже писали на Хабре, Гугл предложил пользователям Интернета постить свои идеи о том, как можно улучшить мир. Запостить свою идею можно до 20 октября. А 27 января 2009 г. начнется голосование пользователей за размещенные идеи, затем те проекты, которые наберут самое большое количество голосов пользователей, рассмотрят эксперты Гугла, и пять лучших идей получат $10 млн., которые пойдут на их реализацию. Проект некоммерческий, и человек, предложивший идею, не получает ничего, кроме осознания того факта, что он помог сделать мир немного лучше.

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

Вот ее краткое изложение:

Это продолжение моей статьи «Клиентская оптимизация и этапы разработки». В ней были даны рекомендации по созданию быстрых сайтов, а в том числе, фактически, я рассказал что должен сделать Web-разработчик, чтобы следовать принципам «Ненавязчивого JavaScript»:

• разделение структуры (HTML) / оформления (CSS) и поведения (JavaScript);
• использование JavaScript для повышения удобства использования уже рабочего приложения;
• применение техники Graceful degradation — если браузер не поддерживает те или иные функции, которые мы добавляем в приложение с помощью JavaScript — приложение всё равно остается рабочим.

В этой же статье я хотел бы рассказать об алгоритме реализации принципов «ненавязчивости» на JavaScript.

Положительные отзывы в хабратопике прибавили нам энтузиазма в плане развития проекта «База классификаторов». И вот что мы сделали.

Во-первых, разделили классификаторы на «Государственные» и «Веб». Это сделано потому, что государственные классификаторы оказались несильно востребованны web-разработчиками, но не выкидывать же информацию если она есть;

Эта статья покажет как настроить PHPIDS. PHPIDS (PHP-Intrusion Detection System) — это легко используемая, хорошо структурированная, быстрая прослойка для анализа безопасности ваших приложений. IDS — не является прослойкой для анализа данных, введенных пользователем, он только распознает, когда пытаются атаковать ваш сайт. на основе набора проверенных и оттестированных правил каждой атаке сопоставлен рейтинг ее опасности. Это позволит легко сохранять статистику по атакам или отсылать уведомления для команды разработчиков.

Зачем может понадобиться писать демоны на PHP?

• Выполнение трудоемких фоновых задач;
• выполнение задач, которые длятся больше, чем время ожидания при HTTP-запросе (30 секунд);
• выполнение задач на более высоком уровне доступа, чем серверный процесс (читай — под рутом).

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

Каждый курс содержит видеозаписи лекций, полные тексты и тезисы, а также практические задания и экзаменационные билеты. Материалы практически полностью совпадают с той программой, по которой учатся студенты-очники в Стэнфорде. Чтобы скачать материалы, не требуется никакой регистрации или специального запроса. Они просто выложены в открытый доступ в ZIP-архивах примерно по 300 МБ, а видеоролики ещё продублированы на YouTube.