Поздравляю, коллеги, с профессиональным праздником!

Не буду долго перечислять пожелания — всё всем и так понятно :-) Ну а кому все же хочется пожеланий — добро пожаловать на Хабр, по такому случаю там целых два топика: первый и второй. А для тех, кому не лень пошевелить мозгами, там же есть набор праздничных головоломок. Сумеете решить?

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

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

Решение 1, читерское.

В условии было сказано, что надо обрабатывать исключения в методах init(), run() и shutdown(). И хотя это явно не оговаривалось, по логике функционирования эти методы вызываются подряд. Следовательно, можно сделать так:

Ну или, чтобы не нарушать инкапсуляцию, этот код можно завернуть в статический метод в ApiDispatcher.

Достоинства решения:

• простота;
• минимум дублирования кода;
• локальность модификации кода.

Недостатки:

• жестко привязываемся к сценарию последовательного вызова методов init(), run(), shutdown(), в реальной жизни может потребоваться вызывать их из разных частей приложения в разные моменты времени;
• метод-обработчик исключений должен очень многое знать обо всех возможных исключениях, при появлении нового исключения придется править метод-обработчик.

Решение 2, логичное.

Следующее решение приходит в голову практически сразу после прочтения условия, и оно действительно хорошо подходит для решения задачи.

Именно его в комментариях предложил Vladimir Rusinov, за что ему спасибо:

Достоинства решения:

• простота,
• независимость от мест вызова методов (то есть, их не обязательно вызывать подряд),
• минимум дублирования кода,
• локальность правок.

Недостатки решения:

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

Решение 3, хитрое.

Это решение в конечном итоге я и использовал в своем проекте. Сначала я приведу код, а потом дам дополнительные комментарии:

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

В PHP все исключения имеют по умолчанию два поля (есть и другие, но они нас не интересуют): $message = null и $code = 0, сообщение и код ошибки соответственно. Во всех наших исключениях мы переопределяем значение по умолчанию для кода ошибки, чтобы оно соответствовало типу исключения.

Теперь, когда мы создаем исключение, мы можем задать ему сообщение, которое описывает причину его возникновения, и, если надо, можем уточнить и код ошибки. Если же мы сообщение вручную не зададим - оно будет получено через класс Errors. В случае, если мы поймаем "не наше" исключение (типа простого Exception), у него код ошибки будет 0, и класс Errors успешно опишет его как "Unknown exception".

Достоинства решения:

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

Недостатки решения

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

Итоги

Я привел целых три решения задачи и видно, что ни одно из них не является безоговорочно правильным. А это значит, что даже такая простая задача, как описано в этом упражнении, требует внимательного анализа требований к системе и ваших возможностей, как ее разработчика. В моем случае решение 3 оказалось наименьшим злом, и я использовал его. Но запросто может оказаться, что в другой ситуации оптимально "наивное" решение 1.

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

Есть корневой класс, условно назовем его ApiDispatcher, который управляет основным потоком исполнения. В нем есть три основных метода:

1. init() — инициализирует, необходимые для обработки запроса объекты.
2. run() — запускает обработку бизнес-логики.
3. shutdown() — освободжает ресурсы.

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

Так же будем считать, что нам на любом этапе доступен метод Client::reportError($error_code, $error_message), который обеспечивает вывод клиенту сообщения об ошибке и прекращение работы программы.

Теперь собственно формулировка проблемы: необходимо во всех трех методах обеспечить обработку всех возможных исключений, для каждого из исключений надо выдать код ошибки и ее текстовое описание, а потом вызвать Client::reportError() с соответствующими параметрами. Замечу, что у исключения может быть задан текст описания ошибки, и в таком случае желательно его сохранить, поскольку он скорее всего будет более информативен, чем стандартная заглушка. В принципе, вы можете модифицировать весь код системы, в т. ч. создавать новые классы и менять существующие, если это необходимо.

Естественно, решение "в лоб" не подходит, поскольку оно неизбежно приведет к большому количеству дублирующего кода.

Как бы вы решили такую задачу? Языки решения принимаются любые в пределах разумного: Java, PHP, C++. Не возбраняется использование языко-специфичных конструкций, если они действительно удобны — расширение кругозора никому лишним не будет ;-)

Я нашел два приемлемых решения, и опишу оба завтра, если их никто не назовет до меня.

Практически всем пользователям знакома утилита top, показывающая интерактивный список процессов, отсортированный по нагрузке на процессор. История этой утилиты идет от 1984 года, когда Уильям ЛеФевр написал такую утилиту для BSD 4.1. С тех пор top или его аналог есть практически в каждой UNIX-подобной ОС.

Годами доказав свою практичность, top вдохновил многих других программистов на разработку похожих утилит, относящихся к разряду must-have на любой Linux-машине, поскольку они дают возможность быстро оценить ситуацию в системе.

htop

htop — это логическое развитие top. Его интерфейс сделан с помощью ncurses, и благодаря этому он предоставляет гораздо больше возможностей по визуализации процессов и общей загрузки системы, а так же значительно более интуитивный интерфейс настройки всего этого.

iotop

Эта замечательная утилита выручит вас, когда надо выяснить, кто же это так активно пишет на диск, что все остальные процессы едва ли не колом стоят: она выводит список процессов, отсортированный по скорости чтения/записи на диск. Полезно запускать ее с ключом -o, тогда она не будет засорять вывод процессами, которые на диск ничего не пишут.

iftop

Эта утилита аналогична предыдущей, но показывает она загрузку сетевого интерфейса. Надо заметить, что в отличие от двух предыдущих программ, она для работы требует прав root'а, и для запуска ей желательно указать имя интерфейса, который ей надо мониторить с помощью ключа -i.

Итог

Все три утилиты (htop, iotop и iftop) позволяют легко и быстро оценить положение дел на вашей машине даже в условиях отсутствия иксов или когда система бодро закапывается в своп и нужно срочно выяснить, почему: в такой ситуации дожидаться запуска графической утилиты — смерти подобно.

PS. Star One — Earth That Was

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

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

Отправной точкой для меня стала почта. Исторически у меня было 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 не так давно напугал всех пользователей тем, что он в скором времени собирается закрыться. К счастью, довольно скоро было объявлено, что апокалипсис отменяется, а у сервиса будет новый владелец.

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

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