Для большинства специалистов PHP не является языком, который бы всерьёз использовался для написания консольных утилит, и для этого есть много причин. PHP изначально разрабатывался как язык для создания веб-сайтов, но, начиная с PHP 4.3, в 2002-ом году появилась официальная поддержка режима CLI, поэтому он уже давно перестал быть таковым. Разработчики Badoo на протяжении нескольких лет вполне успешно используют множество интерактивных CLI-утилит на PHP.

В данной статье нам хотелось бы поделиться своим опытом работы с CLI-режимом в PHP и дать несколько рекомендаций тем, кто собирается писать скрипты на PHP, при условии, что они будут запускаться в *nix-системе (впрочем, почти всё верно и для Windows).

Рекомендации

Скорость работы

Распространено мнение, что PHP — язык медленный, и таковым он является на самом деле. Для PHP CLI рекомендуется не использовать тяжелые фреймворки и даже просто большие библиотеки на PHP по двум причинам:

1. Время работы include/require в CLI-режиме будет всегда включать в себя парсинг и исполнение, т.к. байткод в этом режиме не кэшируется (по крайней мере — по умолчанию), а значит, инициализация займет много времени, даже если из-под веб-сервера всё работает достаточно быстро.
2. Пользователи веб-сайтов привыкли ждать некоторое количество времени для загрузки страницы (около 1-ой секунды, а иногда и чуть больше пользователем воспринимается вполне нормально), а вот сказать то же самое про CLI нельзя: даже задержка в 100 мс уже будет ощутимой, а в 1-у секунду и более может раздражать.

Мне показалось любопытным краткое, но содержательное интервью с Линусом Торвальдсом, пару дней назад взятое у него немецким онлайн-издательством Zeit, привожу его краткий компилятивный перевод по самым важным тезисам.

Мр. Линус, недавно вы высказали свои опасения в связи с усложнением кодовой базы Linux, что вы имели в виду?

Судите сами, на момент когда была создана первая версия Linux — она состояла всего лишь из 10 000 строк кода, на данный момент размер только ядра перевалил уже за 15 миллионов строк. Эта проблема быстрого роста волнует меня уже достаточно давно.

Из-за этого роста сложности, есть также определенная проблема нехватки специалистов соответствующего уровня. Конечно, ситуация, когда в какой-то подсистеме ОС способны разобраться буквально несколько человек — недопустима. Иногда для того чтобы понять, из-за чего появляется какая-то ошибка — мы тратим несколько дней чтобы найти нужного специалиста

Компания Microsoft представила новую файловую систему ReFS, которая будет использоваться в серверной версии Windows 8 и со временем будет адаптирована для настольной версии операционной системы.

Основной акцент в ReFS сделан на хранение данных в сложных системах дисковых массивов. Новая файловая система, являющаяся потомком NTFS, предусматривает различные механизмы повышения надежности хранения данных, восстановления утраченной информации и масштабирования в различных типах дисковых массивов.

ReFS привнесет в NTFS ряд новшеств, уже присутствующих в других современных файловых системах, таких как ZFS и brtfs, популярных в мире UNIX-подобных операционных систем. Например, в ReFS будет использоваться принцип копирования при записи (copy on write), позволяющий оптимизировать хранение данных и упростить процесс создания резервных копий файла. Создание резервных копий файла при каждом изменении позволяет реализовать на уровне файловой системы функционал, аналогичный знаменитой системе Time Machine в операционной системе Mac OS X, позволяющей хранить копию файла после каждого изменения с минимальными затратами дискового пространства.

В мае 2011 года, в расширенном докладе Майкла Рубина (Michael Rubin), занимающегося системами хранения данных в Google (и ответственный в первую очередь за их развитие и масштабирование), прозвучал подробный сравнительный обзор современных файловых систем, в котором, кроме перечисления их преимуществ и недостатков, были даны и некоторые прогнозы о будущем развитии и потребностях информационной индустрии
в этой сфере.

 

Ввиду того, что Эдуард — человек занятой, эпопея с интервью растянулась на неопределённый срок. Но, несмотря ни на что, разработчик reiser4 таки выделил время и ответил на вопросы уважаемого сообщества Хабра и ЛОРа. Что из этого вышло — читайте под катом.

— Как обстоят дела с продвижением reiser4 в ядро?

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

Вообще, продвижение reiser4 в ядро Линукс имеет сейчас низкий приоритет. Просто, потом нужно будет мгновенно реагировать на все изменения в VFS/block layer. А у меня не всегда есть такая возможность. В -mm ветке же никто от меня этого не требует. Если что-то ломается, Эндрю Мортон просто шлёт уведомление. А я, когда нахожу время, исправляю