Друзья, как и было обещано, открываю телемост между нашими головами с целью удовлетворить информационный голод по второй части движка. Что такое МИСО? Конечно, это легендарный японский суп. Первое блюдо, которое пробуют по посещению суши. В чем секрет народной любви к этому явшеству? Он прост, как две капли воды, и необычайно вкусен. В процессе общения в зарождающейся у нас так называемой «стартаперской» среде навязывается привычная западная схема — найти инвестора → снять офис → побатрачить как Папа Карло → создать что-то продающееся → продать проект. Конечно, схема условная, но зачастую именно такая. В целом, это типичный процесс ловли зеленых бумажек, который стал популярен в рамках мировой финансовой системы. Не будем углубляться в рассуждения, каждый имеет свой опыт и делает собственные выводы, но обратим пристальное внимание на ребят из команды 37signals. После первой замечательной книжки под названием «Getting Real» они выпустили вторую — «Rework». Рекомендую к прочтению всем участникам нашей команды. Прочитав ее и осмыслив все написанное, я пришел к выводу, что все это лишнее на данном этапе — офисы, «митинги» в конференц-зале, инвестиции и прочие пряники стартаперской экосистемы. Самые важные компоненты успеха у нас уже есть — опыт и сообщество. Достаточно явно видны цели и поставлены задачи, мы уже научены как надо делать, а как — лучше не стоит.
Поэтому в декабре я принял решение писать вторую версию самостоятельно. Скажем так, создать ядро — задать вектор направления развития. И, как было сказано вчера, сейчас мы переходим во вторую фазу, начиная работать сообща. Вернемся к нашей концепции.
MISO расшифровывается как Make It Simple and Obvious, что в переводе на Великий и Могучий гласит «Делай Это Просто и Очевидно» (ДЕПО, но мне больше нравится первый вариант). Мы убираем все лишнее, избавляемся от балласта, а именно — от рамок фреймворков, от неразумных решений. Следуя данной методологии мы работаем с самым родным, что есть в языке разработки, PHP, — с Объектно-Ориентированным Программированием (ООП) и Standart PHP Library (SPL). В результате мы получаем чрезвычайно гибкий по структуре движок, который построен на современном коде, потребляет в разы меньше ресурсов и обладает рядом конкурентных преимуществ, которые позволят быстро занять свое место на рынке.
Прежде чем принять решение о сложной внутренней структуре своей шестеренки, своего продукта, подумайте — «могу ли я сделать это проще?». Сложную задачу всегда можно разделить на более простые. Простой код более читабелен и его легче совершенствовать, потому что путь от простого кода к → сложному всегда осуществим в отличие от обратного.
Подумайте над этим. Полтора года назад в первой версии я намудрил в некоторых местах, потому как не было такой ясности в происходящем. Сейчас же она есть, на код второй версии приятно смотреть.
Завтра продолжим.

Друзья, разработка второй версии идет полным ходом. Если вы хотите принять участие в разработке, получить доступ к Wiki и репозиторию, пишите в комментах. Добрая половина работы уже позади, и сейчас ко мне присоединились IceDragon и erGo, поэтому работа пойдет быстрее. Мы планируем представить вам новую версию cogear уже в сентябре. Мы постараемся сохранить все те полезности и удобства, за которые вы любите движок, и привнести много новых интересных моментов.
Для более скорой реализации успешной идеи нам пригодится помощь каждого — программиста, архитектора, дизайнера, верстальщика и тестера. Будем рады прибавлению в команде!

Всем привет.

Исследуя внутренности cogear на предмет вкусностей и возможных западлянок в процессе реализации своего проекта, остановился на шестерёнке mail.

Нужна шестерёнка следующего функционала:

1. Анкета доступна любому зарегистрированному пользователю, как расширение профиля.
2. Вопросы анкеты настраиваются через админку.
3. Вопрос анкеты.
3.1. Каждый вопрос анкеты состоит из 3х полей: название, описание, ответ.
3.2. Ответ может быть одним из следующих типов:
3.2.1. Текстовое поле.
3.2.2. Выбор одного варианта из предложенных.
3.2.3. Выбор нескольких вариантов из предложенных.

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

Эта тема посвящена обсуждения функционала шестерёнки «Галереи» и (возможно) процесса её разработки.

Текущие требования к функционалу:

Некоторые мысли относительно контроля прав в Cogear

Что мы имеем, и как сделать лучше?

На данный момент в движке Cogear существует следующая система контроля прав:

субъект права:[множество пользователей (группа)] -> (право на действие) {объект права зависит от acl-записи}
Такая система проста, но не очень гибка — на каждое действие приходится придумывать отдельное право. Кроме того, на некоторые типы субъектов (к примеру, владельца (автора) публикации или комментария) тоже приходится придумывать отдельные acl, и, более того, реализовывать их поддержку в коде модуля.

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