войти зарегистрироваться

KohanaМодуль профайлинга «ProfilerToolbar»

Если вы используете Kohana, то скорее всего уже видели модуль DebugToolbar. Испробовав его на нескольких проектах, стало понятно, что его возможностей явно не хватает. А при использовании Ajax запросов данный модуль становиться вообще бесполезным.

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

ProfilerToolbar

PHPКакой PHP Framework Вы используете?

Проголосовало 1797 человек. Воздержался 531 человек.

KohanaПишем модуль uLogin для Kohana 3.2 из песочницы

Не так давно на Хабре была статья про виджет авторизации uLogin.
Что мне в нём очень понравилось, это возможность указать обязательные поля, при этом, в случае их неполучения от провайдера, пользователю предлагается врчуную их заполнить. Так возникло желания написать модуль в Kohana, который позволял бы легко осуществлять регистрацию пользователя с помощью виджета uLogin.

KohanaИзменения в Kohana 3.2 на русском

Сегодня на хабре уже было сообщение о том, что вышел релиз Kohana 3.2. Я решил в меру свободного времени перевести информацию об изменениях, связанным с этим релизом. В описании собрана информация о самых, на мой взгляд, значимых изменениях.

KohanaЗарелизилась Kohana 3.2.0

image
Поздравляю всех и каждого, сегодня зарелизилась новая версия фреймверка Kohana под номером 3.2.0.

Изменений меньше, чем было при релизе 3.1.0, но и их хватает.

С основным списком изменений и инструкции по обновлении можно ознакомится тут.

Так же к новой версии был подготовлен и новый сайт, который можно наблюдать по адресу: kohanaframework.org/

KohanaАвтоматическая сборка приложения на Kohana с применением Phar

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

Начиная с PHP 5.2, появилась возможность распространять приложения или отдельные его компоненты в виде phar-архивов. Могу ошибаться, но пока такой подход не очень распространен. Я и сам никогда не пользовался таким способом дистрибуции ПО, но совсем недавно решил обратить на него внимание. В качестве эксперимента я выбрал один проект, который «крутится» на фреймворке Kohana. И вот, что у меня из этого вышло.

KohanaРабота с OAuth v2

Предлагаю почитать статью о «прикручивании» второй версии протокола OAuth (он на стадии черновика еще, ага). Сперва немного об общих принципах работы, потом привожу практическую часть (фреймворк Kohana, модуль OAuth).

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

Дико извиняюсь, но топики-ссылки мне неподвластны. Вынужден нагло публиковать в качестве полноценного топика.

KohanaПервичный кэш в Kohana 3 с использованием тегов из песочницы

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

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

Учитывая все это, и в связи с ограничениями используемых хостингов требования были следующие:
  • Кэш должен храниться в файлах.
  • Кэш должен храниться долго, для увеличения скорости извлечения данных и снижения нагрузки на СУБД.
  • При обновлении данных администратором сайта, кэш, содержащий устаревшие данные должен очищаться, причем, очищаться должен не только кэш результатов функций, напрямую извлекающих эти данные из базы, но и тех, результаты которых связаны с этими данными (например, при удалении рубрики каталога должен очищаться кэш списков позиций рубрик). Для достижения этой цели должны поддерживаться теги.
  • Ради достижения цели можно в определенных рамках пожертвовать временем, уходящим на добавление новых материалов, и которое будет затрачено в том числе на очистку кэша, так они добавляются «своим человеком», а не сторонними пользователями.

Стандартный класс Cache_File не поддерживает теги, по этой причине потребовалось писать свой класс, ему было дано имя JetCache.

Класс спроектирован по шаблону «одиночка». Рассмотрим пример работы класса в модели для банка файлов. При инициализации модели создается экземпляр:

$this->cache = JetCache::instance();


Создание кэша данных рассмотрим на примере функции для извлечения списка файлов определенной рубрики (здесь из нее удалены некоторые аргументы и некоторый код для упрощения чтения):

Я пиарюсь Домашние Финансы — Home.Finance.Ua


Уважаемые хабра-люди, в этом посте я бы хотел рассказать об онлайн-системе для ведения домашней бухгалтерии «Домашние Финансы — Home.Finance.Ua»

Свой пост я разделю на две части. Первая из них будет больше домашне-бухгалтерская, где я расскажу что интересного и полезного умеет система. А вторая — техническая, в которой я попытаюсь раскрыть некоторые ее архитектурные особенности. Если для кого-то много букв — на главной странице есть такая большая кнопка «Протестируйте систему ДОМАШНИЕ ФИНАНСЫ», которая ведет в наполненный реальными данными аккаунт.

Веб-разработкаРазмышления о привязке «Войти через...» к одному аккаунту

Постановка проблемы

Некоторое время назад по долгу службы работы, встал на обсуждение вопрос «А нужно ли делать на новом проекте авторизацию через сторонние сервисы?». Мозг, взбудораженный красивыми всплывающими окошками, виджетами и прочими украшательствами, призывно требующими «Войди через меня!», конечно же обеими руками был за, да и современные вебдванольные (а то и, тьфу тьфу, вебтринольные, быть может?) тенденции развития крупных порталов, как бы, намекают. Однако, я не зря сказал, что началось всё с обсуждения, ибо, где есть споры, там есть и камни преткновения. Такой камень мы нашли и здесь.

Предположим, на сайте имеется красивая панелька, как, например, у логинзы, или просто отдельные виджеты авторизации, например, через контакт, твиттер, фейсбук и иже с ними. Легко войти на сайт? Безусловно. Но при этом, если человек войдет сразу со всех этих аккаунтов (одновременно или нет, не суть), для системы это будут разные люди, а следовательно, клоны одного и того же человека, учётной записи которого, быть может, и вовсе нету на сайте.

Казалось бы, какая разница, регистрировать аккаунт на сайте, или входить через внешние ресурсы?