Блоги

Я жив


Я не умер, не забил, не подался в отшельники :-)

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

Стыд и позор, но последняя запись в этом блоге датируется аж ноябрем и это надо исправлять, чем я и постараюсь заняться. Я даже немного приоткрою завесу тайны и скажу, что это будет цикл статей по внутреннему устройству phpBB с точки зрения модописателя. Естественно, будут посты и на другие темы.

Кодекс саппортера.


Вступление

Сила мира open source — сообщество. Фокус силы — его ядро, те, кто поддерживают, развивают свой любимый продукт. И помогают другим полюбить его. Я пишу для тех, кто волей судьбы стал таким человеком, добровольно взвалив на себя тяжелый труд тех поддержки.

Мы — гики

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

Пользователь заслуживает уважения

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

Практически

Уважай себя. Делай так, чтобы тебя уважали другие. «Боятся — значит уважают» — это не про нас. Да и вообще ни про кого, если уж на то пошло.

  1. Будь корректен, ты пример для всех.
  2. Эмоции — плохой помощник, они отвлекают от дела.
  3. Знаешь ответ — ответь. Не знаешь — промолчи. Не уверен, скажи об этом прямо или запроси нужную дополнительную информацию.
  4. Вопрос уже обсуждался — дай ссылку на то, где обсуждался, и закрой тему. Посылаешь в поиск — дай запрос, по которому искать. Придумывать правильные запросы легко, но только когда знаешь, что искать. Ты — знаешь, но пользователь — нет, иначе не спрашивал бы.
  5. Если вопрос требует времени, потрать его. Ведь ты здесь в первую очередь для решения сложных проблем.
  6. Если времени нет, просто молча пройди мимо. У кого-нибудь другого оно найдется и все будут довольны.
  7. Если кто-то ответил неправильно, поправь и объясни, почему его ответ неправильный. Аргументы в духе «ты идиот и кругом неправ» не канают.
  8. Иди на контакт. Не бойся общаться в личке, если это требуется для решения проблемы. Пользователю будет приятно, что тебе небезразлична его проблема, а тебе — что пользователь будет тебе благодарен.
  9. Если тебе хамят, будь еще корректнее. Умение вежливо отвечать на грубость даст тебе лишь преимущество. Напрашивается на бан — забань, но вежливо и согласно правилам.
  10. Наказывай всех. Если кто-то нарушил правила, то он должен получить наказание, независимо от репутации и стажа.
  11. Будь снисходителен. Если ты видишь, что нарушение несущественно и сделано неумышленно, просто объясни пользователю в личке, в чем он нарушил правила и, что больше так не надо делать.
    Это очень важное правило! Я неоднократно убеждался, что пользователи после такого обращения начинают гораздо тщательнее придерживаться правил, чем после бана или ворнинга. Так же важно это обращение делать именно в личке, ибо всякому будет обидно, если его огрехи будут обсуждаться публично. Найти золотую середину между этим и предыдущим пунктом непросто, но очень важно.
  12. Позволь пользователю исправиться и сними наказание. Для тех, кто нарушил правила не со зла это будет очень хорошим стимулом придерживаться правил.
  13. Если пользователь не может исправить нарушение сам, сделай это за него. Права модератора тебе даны именно для этого, а не для нажатия кнопки «бан».
  14. Другие будут уважать тебя тогда и только тогда, когда ты уважаешь других. Так устроен мир.

Если пользователи — дятлы

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

Let's cloud!


Cloud ComputingПризнаюсь, я давно хотел написать этот пост. Уже недели три точно. Однако, учеба и работа успешно съедали все мое время и пост постоянно откладывался. И все же я наконец выкроил свободный вечер и хочу поделиться с вами своими мыслями по поводу облачных сервисов.

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

Отправной точкой для меня стала почта. Исторически у меня было 7 разных почтовых ящиков, которые нужно было читать. Они все были забиты в настройки почтовика на моем настольном компе и на нем же был примерно четырехлетний архив переписки. В итоге, доступ к большей части почты у меня был только из дома, что создавало массу неудобств. В какой-то момент я принял волевое решение настроить сборку почты на моем основном ящике GMail'a и импортировать туда весь архив, заодно сменить kmail на более продвинутый Thundebird и архаичный POP3 на IMAP.

Потратив один выходной, я все это сделал и принялся наслаждаться результатами труда: дома я по-прежнему пользовался почтовиком, с остальных девайсов — веб-интерфейсом GMail. И через пару недель я начал осознавать, что IMAP не вполне корректно работает с ярлыками GMail'a, а основная польза от почтовика — счетчик писем в трее. В итоге, Thunderbird в одночасье оказался заменен на аддон для Firefox WebMail Notifier и веб-интерфейс почты. Так я полностью перенес поту в облако.

Параллельно с этим я стал пользоваться такими штуками, как DropBox (рефералка принесет мне и вам лишних 200 мб бесплатной квоты), с помощью которого я стал обмениваться файлами с коллегами и значительно уменьшил беготню с флешкой от компа к нетбуку и обратно. Read It Later стал перекидывать ссылки на почитать между компами и на телефон. Todoist заменил стикеры и выгодно отличается от них тем, что он не приклеен к одному монитору. Оказалось, что даже для телефона есть его клиент (глючноватый, но есть). Xmarks утащил в облако мои закладки (хотя тут с облачностью можно поспорить, но тем не менее). Жить стало чуточку легче.

Но всему есть цена, и облачность — не исключение. Платить приходится тремя вещами:

  1. Конфиденциальность. Отправляя данные сервис-провайдеру мы должны доверять ему и надеяться, что никто посторонний наши данные не увидит.
  2. Интернет. Облачность практически всегда требует постоянной связи с интернетом. Та же почта — чтобы прочесть старую переписку нам придется подключаться к интернету и потом уже смотреть. В классическом случае с почтовым клиентом весь архив почты у вас на жестком диске и доступен хоть в Антарктиде. Ситуацию смягчает растущая доступность мобильного интернета, но сотовый ведь ловит не везде.
  3. Зависимость от третьих лиц. Решит ваш сервис закрыться или стать платным, и вам придется тратить силы на поиск альтернативы и привыкание к ней. Тот же Xmarks не так давно напугал всех пользователей тем, что он в скором времени собирается закрыться. К счастью, довольно скоро было объявлено, что апокалипсис отменяется, а у сервиса будет новый владелец.

Я довольно долго шел к тому ,чтобы принять эту цену, но в конце концов удобство окупило ее.

А что вы думаете об облаках? Чем пользуетесь или собираетесь использовать? А может у вас есть аргументы против? Мне интересно услышать ваше мнение!

Железобетонные мьютексы в PHP


Alek$ ср, 13/10/2020 - 18:56

Многопоточное программирование, оно такое...Я хочу рассказать об одном нестандартном применении механизма сессий в PHP. Вспомнилось мне это в связи с позавчерашним постом Тормоза на тему, что опять в Даосе проблема с параллельным доступом к файлам - функция блокировки дала очередной сбой. И хотя Тормоз в комментах уже писал, что обкатывает исправленный алгоритм, успешно выдерживающий стресс-тест, я все же поделюсь своим решением. Сразу оговорюсь, все нижеизложенное было проделано just for fun и имеет свои недостатки. Зато и работает практически безотказно.

Перейду к технической части. По умолчанию механизм сессий в PHP использует хранилище данных в файлах - каждая сессия лежит в своем файле. При этом, чтобы обеспечить целостность данных используется нехитрый подход эксклюзивной блокировки доступа к файлу. Иными словами, в момент, когда мы делаем session_start(), движок PHP захватывает файл с требуемой сессией и отпускает ее только в момент явного вызова session_write_close() или завершения скрипта. И если в то время, пока мы работаем с сессией в рамках одного запроса, произойдет еще один запрос, использующий ту же сессию, то он заблокируется на session_start() до тех пор, пока первый не освободит файл. Обычно разные клиенты работают в разных сессиях и проблемы не возникает, однако (немного огрубляю) у одного и того же клиента в один момент времени исполняется только один запрос.

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

  1. Реализуют полностью свой механизм сессий.
  2. Переопределяют обработчики операций с данными сессии во встроенном механизме (с помощью session_set_save_handler(), этим вариантом я в свое время и воспользовался).
  3. Как можно раньше освобождают сессию с помощью session_write_close().

Но я отвлекся. В нашем случае мы не только не будем избавляться от этого, но наоборот будем использовать для реализации мьютекса: будем создавать сессию с заранее известным session_id, к примеру db_mutex, выполнять критические действия и закрывать сессию. Именно эту функциональность и реализует мой класс PHP_Mutex.

Надо признать, такой подход имеет ряд недостатков по сравнению с полноценными мьютексами:

  1. Захватить можно не более одного мьютекса в одно и то же время.
  2. Механизм хранения сессий не должен быть переопределен.
  3. Если вы при этом используете стандартный механизм сессий, возможны потери данных сессии, поскольку на время использования мьютекса блокировка на файл основной сессии снимается.

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

Сам класс вы найдете во вложении, распространяется он свободно согласно лицензии New BSD License. Если кому пригодится - на здоровье :-)

Я в Parallels


С начала октября в моей жизни произошло одно существенное изменение - я стал сотрудником в компании Parallels. Пока лишь как интерн, но в условиях совмещения работы и учебы это оптимально, особенно при таком печальном расписании как в этом семестре :)

 Конечно, почивать на лаврах было бы глупо - уволят нафиг, но это в мои планы и не входит, поскольку наша команда будет работать над новым и интересным проектом, что вообще большая удача для меня. Удача потому, что большая часть программистского труда в крупных компаниях приходится на поддержку и развитие уже существующих проектов, со всеми их "исторически сложившимися" архитектурными костылями и задачами. Тут всегда найдутся темные куски кода, которые никто до конца не понимает или баги, бережно хранимые во имя обратной совместимости. А начало нового проекта - это шанс поучаствовать в гораздо более творческом процессе, поработать над архитектурой, исследовать технологии и не задумываться об обратной совместимости, до тех пор, пока проект не перестанет быть новым ;)

Что касается самой компании Parallels, то в зону моего внимания она попала достаточно давно, однако ее продукты у меня вызывали самые разные чувства. Два основных продукта, с которыми мне приходилось иметь дело - это Parallels Plesk Panel и OpenVZ.

С OpenVZ дело обстояло довольно просто, года два назад (офигеть, этому блогу уже два с половиной года и он мне еще не надоел) у меня случился пик интереса к технологиям серверной виртуализации и я естественно не мог обойти вниманием OpenVZ. Тогда я получил массу удовольствия, играясь с контейнерами и прикидывая, для чего оно мне могло бы сгодиться в хозяйстве, но так и не придумал и отложил в долгий ящик. Но теплые воспоминания остались. Позже я столкнулся с этой технологией уже как клиент и на данный момент обе мои VPS работают именно под этой технологией.

А вот с Plesk'ом у меня отношения сложились не так гладко. Года эдак три назад я работал с один человеком, у которого на VPS (точные параметры уже не вспомню, но довольно мощной) был установлен Plesk 7. Это было нечто. С одной стороны, он жрал почти половину памяти сервера даже в простое, держал много файловых дескрипторов и давал небольшую, но постоянную нагрузку на проц за счет постоянно запущенного собственного демона. В результате, сайт весьма основательно тормозил и падал с разными ошибками о нехватке ресурсов. Ну а интерфейс меня вообще приводил в тихое отчаянье: сделанный в стиле Windows XP он требовал для каждого осмысленного действия 3-4 перехода со страницы на страницу, каждый из которых происходил секунд по 10-15 еще и блокируя все действия на время загрузки страницы. То есть, если ты промахнулся и кликнул не туда, то ты не кликаешь тут же куда надо, а ждешь 10 секунд, пока загрузится ненужная тебе страница, потом еще 10 - пока вернешься назад и еще 10 - пока грузится та страница, куда ты хотел изначально. К счастью, клиент был вполне солидарен со мной и мы волевым решением избавились от панели управления вовсе, благо особой нужды в ней не было - на впс жил всего один сайт. С тех пор моими любимыми панелями стали Kloxo и ISPManager за легкость и эффективность.

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