Автор: admin

update kernel-headers на CentOS

Цитирую полезную статью, оказался в точно такой же ситуации при покупке VPS на Agawa

Установка GCC

Сразу после регистрации сервера вам может потребоваться установить GNU C++ Compiler. Когда я первый раз настраивал аккаунт на Агаве, он был уже установлен, однако на новом аккаунте он почему-то отсутствовал. Поэтому его потребовалось установить:

yum install gcc-c++

При установке может возникнуть ошибка

Error: Missing Dependency: kernel-headers >= 2.2.1 is needed by package.

В этом случае необходимо обновить пакет kernel-headers. Я его ставил отсюда:

wget ftp://ftp.pbone.net/mirror/ftp.centos.org/5.2/os/i386/CentOS/kernel-headers-2.6.18-92.el5.i386.rpm
rpm -i kernel-headers-2.6.18-92.el5.i386.rpm

После этого все должно ставиться нормально.

redirect 301

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

10.3.2 301 Moved Permanently

The requested resource has been assigned a new permanent URI and any
future references to this resource SHOULD use one of the returned
URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is
cacheable unless indicated otherwise.

The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s).

If the 301 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.

Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request.

Ага, значит при обращении поисковика по старому URL нам нужно произвести редирект со статусом 301.

Для этого в файлике .htaccess прописываем
redirect 301 /old/path.html /new/path.html

Не забудьте заменить пути из примера на ваши страницы 😉

PHPUnit Fred Yankowski

Есть несколько реализаций PHPUnit (php реализации известного пакета тестов JUnit). Первая, пожалуй каноноческая, версия господина Бергмана . Вторая реализация принадлежит Фреду Янковскому. Недавно решил ее посмотреть . Меня сильно озадачило то, что тесты ни в какую не хотели работать. Чтоб отловить багу реализации влез в код. Оказалось Янковский, шут поймет из каких побуждений, попробовал переопределить ( не наследовать) класс Exception разумеется движок не захотел это глотать. Я удивлен, что это как-то раньше работало, видно php4 это еще хавал. Не долго думая я изменил название на UException и заработало.

ASP.NET — пути для javascript

На первом этапе знакомства с ASP.NET был я сильно удивлен непродуманностью управления путями к клиентским сценариям. По причине неизвестных мне особенностей самой технологии или ее разработчиков рендеринг корркетно обрабатывал только ссылки стилей при использовании значка корня «~». С javascript сценариями все было довольно плохо. в первый раз получилось их подрубить только при вводе относительного пути. Но при добавленнии masterpage и нескольких подпапок для страниц с разной логикой начался кошмар, поскольку никакого динамического преобразования путей к клиентским сценариям не происходило. Я проклинал Майкрософт, проклинал ASP.NET, проклинал всю команду разработчиков этой технологии. Прошерстив немного интернет я нашел выход. Для преобразования абсолютного урла в динамический правильный относительный путь можно воспользоваться методом ResolveClientUrl класса Controll. Собственно поскольку сама страница так же является контроллом пишем внутри аттрибута src:

<%= ResolveClientUrl("~/frontend/js/jquery-1.3.2.min.js") >

Вот что написано в официальной документации:

Метод ResolveClientUrl используется для возвращения строки URL-адреса, подходящего для использования клиентом для доступа к ресурсам веб-сервера, таким как файлы рисунков, ссылки на дополнительные страницы и т.д. URL-адрес, возвращенный этим методом, определяется относительно папки, содержащей файл источника в котором создан элемент управления. Элементы управления, которые наследуют это свойство, например и MasterPage, возвращают полный URL-адрес относительно элемента управления

ECHO or PRINT

Вопрос который возникает у любого начинающего php программиста, когда он открывает для себя великую истину — «не все функции работают одинаково быстро», что быстрее print или echo? На самом деле любой мог бы сам это проверить. Но новичку эта идея не всегда приходит в голову.

Несколько коротких выводов из моего опыта и попутно упомяну несколько важных особеннностей:

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

поэтому плюньте и учитывайте только в действительно больших итерациях, правда и тут под вопросом, автор статьи по данной ссылке даже при 20 000 000 итераций добился лишь 0,16% выигрыша производительности. используйте то, к чему вы привыкли

Особенности:

  • print ведет себя как функция, то есть возвращает значение (int 1)
  • echo поддерживает вывод нескольких параметров разделенных запятой, что быстрее чем вывод с конкантинацией, который единственно доступен для print.