Взял VPS, построенный на OpenVZ. Поставил туда Debian Lenny и всякие программы (обычный LAMP, по сути). С точки зрения потребления ресурсов ничего почти не настраивал, вышло где-то 200М занятой оперативной памяти (сразу после старта).
Написал ulimit -s 1024 в /etc/init.d/rc ближе к верху. Перезагрузился. Потребление памяти на VPS упало более чем вдвое, стало около 100М.

Если у Вас VPS на Xen или аналогичных, то у Вас нет граблей, с которыми я тут боролся. Если на OpenVZ (Virtuozzo) со товарищи — у Вас, скорее всего, на VPS эти же грабли.

В статье — почему и как это работает.

На Хабре достаточно много разработчиков работают с файлами на удаленных хостах. На локальной машине запускается IDE, отладчик, все необходимое, а сами файлы находятся на сервере, где они регулярно бакапятся, автобилдятся, тестируются и так далее. Очень удобный рабочий вариант. Да я сам его использую.
Единственная проблема, доставляющая неудобство — файлы все же находятся на другом компе, и доступ к ним не такой простой и прозрачный как к «своим».
Под катом — как сделать такой доступ максимально удобным. Чтобы он запускался автоматом когда надо, а самое главное — чтобы не запускался, когда не надо!

По следам хабратопика о Watir, автоматизированном иструменте тестирования для web приложений на языке Ruby, решил написать небольшую статью о подобном инструменте для языка Python. Речь пойдет о замечательной библиотеке mechanize. В отличие от Watir, mechanize не заточен под какую-либ о ОС, и является надстройкой над питоновскими библиотеками urllib и urllib2.

Сама библиотека является эмулятором браузера (без поддержки яваскрипта) и позволяет решать задачи любого класса (с огладкой на «отключенный» яваскрипт), в которых необходим применение браузера. В частности, я впервые вышел на эту библиотеку, когда нужно было скачать огромное количество научных статей с одного хранилища, требующего авторизации и хранящего документы PDF так, что без помощи вспомогательных инструментов скачивать приходилось исключительно по одному документу, чем я и занимался 2 часа, пока не вспомнил о PERL'овой библиотеке WWW::Mechanize (о возможностях которой читал некоторое время назад) и не набрал в гугле запрос WWW::Mechanize python, который и привел меня на сорсфорж.

Но довольно лирики.

Вице-президент Google, Марисса Мейер, на конференции Web 2.0 поведала историю об одном пользовательском тестировании. Группа пользователей Google была опрошена на предмет, сколько результатов поиска они хотели бы видеть на одной странице. Те просили показать побольше, больше чем те 10 штук что поисковик выдаёт обычно. «Много не мало», говорили они.

Специально для них, Гугл увеличил выдачу до 30 результатов. Объём трафика и доходность сократились на 20%.

Почему им не понравилось? Ведь всё было сделано именно так как они сами хотели.

Оказалось, изменилось кое-что ещё. На генерацию страницы с десятью результатами у сервера уходило 0,4 секунды, на страницу с тридцатью — 0,9.

Всего лишь полсекунды разницы уменьшило трафик на 20% и испортило впечатление пользователей о сайте.

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

Потом Марисса рассказала что после того как, в своей новой версии, страницы Google Maps стали весить меньше, а карты отрисовываться быстрее, объём трафика незамедлительно вырос, как и использование сервиса вообще.

Урок в том, сказала Марисса, что скорость имеет значение. Люди не любят ждать, так что не заставляйте их делать это.

Via Fresh GUI.

Какое-то время назад потребовалось перенести проекты с выделенного сервера на VPS. Для этих целей был выбран slicehost. В общем и целом контора нравится и готов её рекомендовать всем.

Случилась лишь одна проблема: начали приходить уведомления о слишком сильном использовании диска (чтение/запись). Долгое время проблема не находила решения из-за отсутствия времени, но это вылилось в непонятные отказы, сопровождавшиеся статистикой в >200% CPU usage. После долгих извращений, была найдена проблема, а затем и её решение.

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

Начало

Пару недель назад я заметил странную активность, направленную на мой DNS-сервер. Сразу скажу, что использую шлюз на Linux, соответственно там установлен DNS-сервер bind. Активность заключалась в том, что на порт 53 (DNS) моего сервера сыпалось по несколько UDP пакетов в секунду с различных IP-адресов:

10:41:42.163334 IP 89.149.221.182.52264 > MY_IP.53: 22912+ NS?. (17)
10:41:42.163807 IP MY_IP.53 > 89.149.221.182.52264: 22912 Refused- 0/0/0 (17)

В то время, как фанаты экзотики на хабре активно пьют чашки с Java, принимают дозы F# и вкалывают себе прочий Haskell, мы с вами учились собирать их творения в deb-пакеты. За прошедшее с предыдущей части время у кого-то наверняка уже накопилось несколько готовых пакетов, а в официальный репозиторий Debian и Ubuntu мы их пока помещать даже не пробовали. Поэтому настало время подумать, каким бы образом организовать всё накопленное богатство в один большой красивый репозиторий, который не стыдно будет предложить для использования и другим пользователям.
(Части 1, 2 и 3)

И был день третий, и задумался хабрапользователь-убунтоид: а как мне запаковать свой любимый пакет, чтобы был он красивый и правильный и чтобы гордость от его кошерности распирала ого-го как. Именно этим мы с вами сегодня и займёмся.
(Части 1, 2 и 4)

Компания ОСМП – лидер на рынке платежных терминалов. По всей России установлено уже более 80 000 штук. Думаю, что многим интересна возможность получить в свое распоряжение столько касс, принимающих оплату 24 часа в день за ваши заказы! Для сравнения, у Сбербанка всего порядка 20 000 отделений по всей стране.

Ну как туда попасть?

Во время шумихи с аськой и предложениями перехода на 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. Спасибо за приглашение на хабр! Решил перенести свою статью из песочницы в блог.

Иногда в проекте требуется проверить данные на предмет орфографических ошибок, не полагаясь на познания пользователя по части языков. Тут нам сможет помочь компания 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

В тот день, когда Грубер (Gruber) впервые опубликовал интерфейс TripLog/1040 от Stevens Creek, я был настроен неблагосклонно. Цвета — яркие, элементы управления казались расположенными в совершенно случайном порядке. Это шло вразрез со всем тем, за что ратуют наши дизайнеры. Просто бардак. Вскоре страница на Flickr превратилась в площадку для нападок и оскорблений. Но тут случилось нечто весьма интересное. Дизайнер TripLog Стив Патт (Steve Patt) посреди всего этого потока желчи опубликовал комментарий, в котором поделился той логикой, что в конечном счёте привела к такому варианту дизайна. Те, кто предпочёл его не слушать, ничему не научатся, но остальные могут многое почерпнуть из наводящего на интересные мысли объяснения и двадцатилетнего опыта мистера Пратта в разработке ПО.

Уровень сложности: начальный

Вводный обзор стандартных инструментов GNU/Linux должен помочь начинающим пользователям Linux контроллировать работу ОС. Используемые приложения, как правило, включены в поставку известных дистрибутивов. Полезным побочным эффектом я считаю возможность сориентировать молодых системных и сетевых администраторов в условиях [подозрения] компрометации.

Совсем немного теории

Исторически сложилось так, что в X Window System (X11, — оконная система для Linux, UNIX) существует два буфера обмена.

Один из них (clipboard) похож на буфер обмена в Windows — при нажатии на Ctrl+Insert или Ctrl+C выделенный фрагмент (текст, картинка, файл) копируется в буфер обмена, а при нажатии на Shift+Insert (или Ctrl+V) — вставляется из него. Следует заметить, что во многих программах эти сочетания зарезервированы для иных целей и приходится пользоваться другими — например, в терминале сочетание Ctrl+C используется для завершения процесса, а для работы с буфером обмена используются сочетания Ctrl+Shift+C для копирования и Ctrl+Shift+V для вставки.

Второй буфер (primary) является специфичным для оконной системы X11. Выделенный текст незамедлительно попадает в буфер primary, и для того, чтобы вставить скопированный текст, достаточно лишь нажать среднюю кнопку мышки (колёсико). У кого в наличии не имеется трёхкнопочной мышки, а так же владельцам ноутбуков с тачпадами следует одновременно нажать левую и правую кнопки мышки для вставки текста.

В продолжение темы Настройка Ubuntu 8.10 для кодинга под NVIDIA CUDA, я решил наладить себе рабочее место для использования одного из моих любимых языков программирования — Python. Для этого существует отличный набор библиотек PyCUDA, позволяющий реализовывать все прелести NVIDIA CUDA API с помощью удобного и красивого кода.

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

Победа заключается в том, что моя программа официально включена в релиз Ubuntu 8.10. Началось всё с того, что на LinuxForum я создал тему, в которой предлагал способ сделать ОС Linux более доступной для новичков. Многие линуксоиды против так называемых «GUI для редактирования конфигурационных файлов», но я считаю, что необязательно новому пользователю Linux разбираться в устройстве работы ОС, чтобы получить требуемый ему результат. Возможно, такое отношение к GUI программам такого рода вызвано состоянием большинства таких программ, ведь они действительно «нечеловечны». Доходит до того, что для получения результата легче понять увиденный в первый раз конфигурационный файл, чем GUI программу. Именно поэтому я решил попробовать создать такой инструмент для обычных пользователей, который был бы понятен и удобен всем. На данный момент результатом является MountManager 0.2.4, который и был включён в самый популярный дистрибутив мира.

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

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

Что такое представление?

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

Представления иногда называют «виртуальными таблицами». Такое название связано с тем, что представление доступно для пользователя как таблица, но само оно не содержит данных, а извлекает их из таблиц в момент обращения к нему. Если данные изменены в базовой таблице, то пользователь получит актуальные данные при обращении к представлению, использующему данную таблицу; кэширования результатов выборки из таблицы при работе представлений не производится. При этом, механизм кэширования запросов (query cache) работает на уровне запросов пользователя безотносительно к тому, обращается ли пользователь к таблицам или представлениям.

Замена apt-mirror`у

apt-cacher — утилита для Debian-подобных дистрибутивов использующих apt в качестве установщика пакетов. Она кеширует файлы, которые скачивает пользователь с офф. зеркала обновлений и при следующем запросе выдает их из своего кэша.

Если вы разрабатываете программы на Питоне, то, уверен, вы хорошо знакомы с работой с ним в интерактивном режиме. Это самый простой и удобный способ проверить пришедшую в голову идею, запустить библиотечную функцию, пошагово прогнать какой-то алгоритм и т.п. без создания лишних мусорных файлов. Вобщем питоновская консоль — очень мощная и удобная вещь. У меня постоянно напрашивается сравнение с юникс-шеллом в языке. Если бы не две ложки дегтя в этой бочке меда: команду каждый раз приходится набирать заново, вместо того, чтобы просто нажать стрелку вверх и подправить команду, а также приходится писать много лишнего, что только добавляет опечаток и необходимости повторного набора. Вобщем я хочу как в баше: история + автодополнение.
Я удивлен почему это еще не сделано по умолчанию. Кстати, очень может быть, что это уже реализовано в вашей системе, и вам это совершенно неактуально — тогда можете совершенно смело пропустить эту статью. Возможно это пригодится кому-то другому. На попавшихся мне Macos, Freebsd, Debian и Fedora этого не было.