Приветствую вас, уважаемые хабралюди!

Хочу предложить вашему вниманию видеокурс моего производства по фреймворку Kohana 3.1.

Что за видеокурс такой и кому он нужен: видеокурс бесплатный, доступен без предварительной регистрации — я не последователь Азамата Ушанова (да-да, такие еще остались, но нас очень мало).

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

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

На кого рассчитан видеокурс: начинающие веб-мастера, желающие перейти от программирования на чистом PHP к MVC-фреймворку.

При знакомстве с фреймворком, я первым делом смотрю не на его возможности, а на готовые решение, которые он предоставляет. В частности возможность удобно собирать JS/CSS файлы по частям и «отдавать» согласно рекомендациям по клиентской оптимизации (YSlow/Google PageSpeed). Ни в одном из просмотренных мной, нужной мне реализации я не увидел, даже в Django (которым, собственно, и был вдохновлен), поэтому решил сделать свое решение в виде готового к применению модуля для Kohana v.3.

Итак, опишем основные потребности/хотелки, которые ставились перед разработкой модуля:
1) Сборка inline CSS/JS по кусочкам
2) Возможность отдавать п.1 путем вставки в код страницы либо сгенерировав и записав на диск файл, с уникальным именем.
3) Возможность сборки внешних файлов CSS/JS в один билд
4) Возможность указывать условие, при котором подключается тот или иной билд из пункта 3, а также любой другой внешний файл (

<!--[if IE 7]>

).
5) Возможность вынести статику на другой домен, главное чтобы он был на этом же физическом сервере.
6) Использование CDN
7) Минимизация CSS/JS.
8) Самое важное: СПОСОБ, позволяющий включать статику (а эо обычно не только CSS/JS, но и, например. картинки) в распространяемые модули. Так как текущий способ, когда в modules/ переносится и подключается сам функционал модуля, а статика либо копируется в произвольное место DOCUMENT_ROOT, либо обязательное условие – чтобы modules находилась в DOCUMENT_ROOT.
9) Возможность легко менять URL со статикой, чтобы он никак не конфликтовал с роутингом, например будет не хорошо, если вы захотите иметь раздел про CSS по урл ”/css/” когда до этого вы сделали это реально существующей директорией с файлами стилей.

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

Эту статью давно стоило переписать (слишком много «экономии на спичках»), но руки не доходят. Пускай весит и напоминает о том, как мы глупы в молодости.
Одним из основных критериев успешности любого интернет-ресурса является скорость его работы и с каждым годом пользователи становятся всё более и более требовательными по этому критерию. Оптимизация работы php-скиптов — это один из методов обеспечения скорости работы системы.
В этой статье я бы хотел представить на суд общественности свой сборник советов и фактов по оптимизации скриптов. Сборник собирался мною достаточно долго, основан на нескольких источниках и личных экспериментах.

Очень часто возникают проблемы при сетевой печати на принтеры, подключенные
например, к компьютеру с Windows XP на компьютере с установленной ОС Window 7,ненаVista,2003,2008

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

Вот и у меня сложилась такая ситуация:

Знакомый попросил настроить печать в офисе со свежекупленного ноутбука.

1. Конечно же — ноутбук был с операционной Windows 7
2. Конечно же — Home (см. ниже в чем проблема)
3. Конечно же — она (система) была 64-х разрядной.
4. Конечно же — принтеры в оффисе были не новые: HP1320 и Canon MFxxxx
5. Конечно же — принтеры были подключены и «расшарены» на машинках с WinXP.
6. И никто не будет менять структуру сети ради одного ноутбука

Fuel — это простой, гибкий, управляемый сообществом php5-фреймворк, родившийся благодаря разочарованию в имеющихся инструментах. Таким слоганом нас встречает сайт фреймворка — fuelphp.com.

Разработчики — Dan Horrigan, Phil Sturgeon, Jelmer Schreuder и другие участники сообщества. Ребята являлись (являются?) активными участниками сообщества Codeigniter, но разочаровались в темпах его развития (сейчас разработка Codeigniter ведется более активно, на два фронта — Codeigniter Core и комьюнити-драйвен-версия Codeigniter Reactor). В результате родился Fuel. Что ж, давайте рассмотрим его поближе.

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

Fat-Free чем-то похож на известный Ruby-фреймворк Sinatra. Автор Fat-Free помешан на минимализме и чистоте кода, что положительно отразилось на этом простом каркасе для разработки самых разнообразных приложений.

Fat-Free состоит из одного файла и весит всего 55KB. При этом фреймворк обладает таким функционалом: специфический и довольно удобный шаблонизатор, гибкое кеширование, автоматическая защита от спама, интегрированные средства для юнит тестов, профайлер кода.

Он настолько маленький и быстрый, что даже может использоваться для контроля траффика Web-сервера.

Это, также, единственный фреймворк, который защищает Ваше приложение от хотлинкинга и DoS атак.

Сейчас практически на каждом сайте есть кнопки для перехода на сайт твитера или добавление странички в закладки. Но почему-то очень мало можно увидеть иконок Wikipedia возле фамилий великих людей или терминов.

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



Если учитывать, что только активные пользователи нажмут на кнопку «Оставить свой отзыв» и проголосуют, то наверно 33 голоса можно умножить на 10 – 100.

Разобравшись с api Wikipedia хочется предложить решение как можно немного автоматизировать добавление линков на википедию.

Доброго утра, дорогие Хаброчитатели!

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

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

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

Итак, для себя я сформулировал задачу по следующим криетриям:

1) Каждый модуль должен содержать все необходимое для работы в одной папке — и шаблоны, и модель, и контроллер. Дабы его легко можно было скопипастить, подправить — и вуаля — новый модуль.
2) Модуль ничего не должен знать о тех, кто его создает — все необходимые ему для работы данные он получает через конструктор. Это для того, чтобы модуль работал не только на моем сайте, но и на всех сайтах моих друзей и клиентов без всякого допиливания напильником.
3) Для того, чтобы пользоваться модулем его не должно быть нужно где-либо регистрировать или инклудить дополнительные файлы. Это тупо раздражает.
4) Модуль может состоять из модулей. Т.е. должна быть поддержка вложенных модулей.
5) Ссылки (a href=...) внутри шаблонов модулей должны быть относительными, не зависящими от того, на какой глубине вложенности находится модуль. Чтобы банально не править шаблоны, если мы перемещаем модуль из одного родительского модуля в другой.
6) Сам сайт тоже должен быть модулем, раз уж на то пошло. Дабы можно было купить у друга уже рабочий сайт, положить себе в папку и встроить весь его на какую-нибудь страницу без лишних переделок.

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

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

Мне часто задают вопрос о том, с чего начать молодому frontend-разработчику? Дабы облегчить свою участь и не перечислять каждый раз множество ресурсов сети, печатных и зданий и общих тезисов, я и написал этот материал.

В первую очередь следует знать, что кроссбраузерная верстка сродни магии. Объясняется это все банальной вещью, которую я озвучу так: ”Все мы ненавидим Internet Explorer!” Таким образом, 90% всей магии сводится к тому, чтобы заставить правильно сверстанный макет корректно отображаться в браузере Internet Explorer всех актуальных версий.

Чтобы научиться сему мастерству потребуется практика, много практики. И сев сейчас серьезно изучать аспекты верстки, вы и через полгода будете удивляться, сколько вы до сих пор не знаете.

Крепкая теоретическая база поможет вам избежать множества неприятностей в практическом изучении верстки гипертекстовых документов. Очень важно получать знания порциями в правильном порядке.