Итак, мы начинаем обратный отсчет до беты. Каждый день на сайте будет публиковаться материал «по ходу работы», из которых впоследствии будет формироваться документация или вики. Друзья, я пришел к выводу, что самым главным для меня является ваша поддержка. Когда я вижу, что хорошим людям для реализации реальных проектов требуется движок, тогда я сильно мотивирован достичь результата и произвести общее благо. Поэтому я прошу каждого из вас, даже тех, кто читает сайт молча, проронить хотя бы слово в течение последующей недели. Это важно для меня. Это важно для всех нас.
Бета-версия будет являться простой демонстрацией возможностей системы, поэтому сразу скажу, что не стоит ожидать от нее чудес. Я притащил изумруд, давайте вместе обточим его и превратим в бриллиант. Моя сила — в вас, и наоборот. Из ваших слов и поступков я черпаю вдохновение и заряд энергии для последующей работы. Будем постоянно на связи.

Насущных вопроса два.
Первый. Хочется реализовать глобальную иерархию и связи, на которые уже потом бы цеплялись объекты разного рода. При помощи наследования каждый объект можно было бы отпочковать от родительского, и вот они уже — посты, опросы, комменты и так далее. Кроме того, можно повесить на эту же иерархию и структуру страниц. А реализовать ее посредством простой таблички в БД и Materialized Path, во избежание лишних нагрузок. А ведь «дружба», «закладки», «мне нравится», «читать блог» — это ведь просто разные типы связей. Консолидировав все это в единое целое, мы сделаем большое дело.
Второй. Надо унифицировать системы вывода. Причем как элементов формы, так и страницы. Совместить с постраничной навигацией, бесконечным скроллингом и табами. По сути, это одно и то же.

С радостью слушаю пожелания и предложения.

Доброго воскресенья, друзья! К работе над второй версий активно подключаются участники команды, что определенно радует. skvorets уже рисует новый интерфейс админки, JiLiZART стоит на страже багов в GIT-репозитории, inetlover продумывает интерфейсы и готовится к верстке, Varhal и Osiris вот-вот запустят сайт с темами для первой версии. Самое время продолжить вводный курс в архитектуру второй части. Хочешь принять посильное участие в общем деле? Пиши в личку!
Что является наиболее важной задачей для разработчика системы? Преемственность разработки, чтобы другие люди легко включались в оригинальный код и могли быстро реализовать собственные разработки на базе исходной. Да, конечно, это лишь часть успеха, но без преемственности нет жизни. Говорят, мы живем в наших детях. Могу перефразировать в аспекте движка — система живет в сообществе.
Итак, моя задача до релиза второй версии привести нас с вами к общему знаменателю, чтобы все понимали, что происходит внутри, и осознавали архитектуру движка самостоятельно, а не только с моих отзывов в духе «Это просто супер!» :-)

Друзья, спешу поделить с вами новостями с фронта разработки. Релиз альфы задерживается прежде всего потому, что я работаю один. Сообщество еще не вышло из зимней спячки, и это положение пора менять. Каждый день сайт проект посещает порядка двух сотен человек. Если мы все будем делать по-немного, работа пойдет намного быстрее. К примеру, последние две недели я боролся с гриппом, и работа стояла. Такого быть не должно. Буду рад любой помощи на этом нелегком пути.
Давайте о хорошем, то есть о движке. Все получается на редкость складно, понятно и удобно. С месяц тому назад я в очередной раз пришел к выводу, что излишне усложняю процесс, желая предоставить вам как можно больше свободы. Это я о Zend Framework. Зачем ради классов БД, кеша и ридера конфигов подключать библиотеку, общий размер которой порядка 25Мб? Правильно, и я так подумал. Поэтому решил отказаться от Зенда по-умолчанию, заодно вернув первозданную легкость в работе с БД аналогичным по-синтаксису, бывшим в CI. Первые плоды не заставили себя ждать — потребление ресурсов снизилось в 10 раз.

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

• Высокое потребление ресурсов на генерацию кода формы.
• Не оптимизированный код, переписать который проще, чем исправить.

Во всем остальном, особенно в скорости разработки, они были хороши.

Что же нас ожидает во второй версии? Разработка дошла до 80% готовности Form API, но есть чувство, что я заблудился, поэтому призываю вас на помощь, чтобы решить — какими же будут формы в cogear².

Доброго времени суток, друзья! Продолжаем околокогирные разговоры, и сегодня речь пойдет о механизме наследования шестеренок.
Для тех, кто в танке или по каким-либо иным причинам еще не прочитал дюжину умных книжек по PHP (или по ООП), скажу пару слов о сути явления.
У каждого из нас есть родители, от которых мы наследуем добрую половину особенностей. Также и в объектно-ориентированном программировании — новый класс может «отпочковаться» от родительского. Зачем это все? Представьте, вы решили создать несколько объектов разных марок автомобилей. Здесь вступает в силу системный анализ — структуризация, упрощение и приведение к общему знаменателю. Создавать объекты автомобиля каждой марки, когда между ними столько общего — четыре колеса, форма кузова, принцип работы двигателя и далее по списку? Увольте. В таком случае создается базовый класс автомобиля, а дочерние классы марок описываются только особенностями, которыми они отличны от родителя. Думаю, теперь все поняли, в чем смысл наследования — упрощение и обобщение с целью сокращения времени разработки. Здесь же имеет место быть еще одно преимущество — для изменения всех дочерних классов можно внести изменения только в родительский.

Продолжаем курс вводных топиков во вторую часть cogear. Следует помнить, что следуя концепции МИСО мы стараемся сделать все просто. В прошлом полугодии ваш покорный слуга сполна вкусил системного анализа, поэтому и здесь мы структурируем и определяем взаимосвязи, а после целое делим на элементы и приводим их к общему знаменателю. Ни для кого не секрет, что в первой версии мы ввели свое обозначение компонента системы — шестеренка. Почему? Потому что мы называем CMS движком, а как CMS состоит из компонентов, так и внутри движка трудятся шестеренки, обеспечивая его работоспособность. Во второй части мы продолжаем развивать эту философскую линию. Мы убираем .info файлы, как характеризующие шестеренку, и ставим на их место классы на PHP. Настройки переезжают в базу/кеш (пока, непонятки при обновлении!), вся структура определяется внутри класса. Кроме того, теперь разработчик сам волен распоряжаться структурой свой шестеренки, ведь любые ограничение на файлы и папки сняты.

Продолжаем вводную часть второго cogear. Сегодня речь пойдет по файловой структуре.
Правильная организация внутренних компонентов позволяет сделать расширяемой и легко обновляемой. Когда я слышу удивленное «Как, ты работаешь с Wordpress?», всегда улыбаюсь, потому что большая часть холиваров возникает на пустом месте. Я работаю с теми системами, которые мне интересны, и бытие мое как автора cogear совершенно не препятствует мне делать сайты на других системах. Исследуя их, я нахожу сильные и слабые стороны, и как следствие, видение идеального движка расширяется и трансформируется на разных стадиях.
В процессе разработки cogear² выбор пал на синергию занимательных концепций в веб-программировании:

• Пространство имен классов и автозагрузка. Zend Framework
• Мультисайтовость. Drupal
• Концепция «слоеного пирога». Kohana

О том, как три указанных особенности переплелись друг с другом в новом когире, мы с вами и поговорим.