Рассладование вывело на тикеты 4-ех месячной давности. Проблема наблюдается только с небольшими файлами (до пары килобайт). При работе с объемными библиотеками таких проблем не наблюдалось.
Тикет помечен как ресолвед, проблема в теории решается обновлением VB до последней версии и обновлением гостевых дополнений. Только вот беда в том что я обновил все… а проблема осталась. Вот жду когда мои JS библиотеки разрастутся — тогда проблем не будет. А так, нужно думать в сторону самбы все же… там хоть стабильно и быстро.
Такие ситуации сплошь и рядом. Во всем обычно вина изначальное непонимание с одной из сторон концепции (как правило заказчик не может внятно объяснить чего он хочет). Вот и со мной так сталось… Уже 3 месяца прошло как меня посадили на один «висяк»… Изначально планировалось что на основе той CMS, которую мы писали заказчику, мы будем делать внутренние проекты, а так как у меня имелись кое-какие наработки — решили назначить меня… время шло… тимлид ушел, так что продвигать внутренний проект больше некому… необходимость в моих компонентах осталась… а заказчик шлет бесконечный список багов и чейндж-реквестов… Дико достало, причем не только меня но и руководство. Единственное что останавливает — контракт) Вроде бы проект вышел в лайф… да вот только, судя по моим таскам назревает следующая версия этого проекта. Я буду настаивать на переработке кода отдельных компонентов так как фиксить баги там нереально…
В вашем случае еще такое решение подойдет… У вас сайдбары спозиционированны обсалютно… Посему можно сайдбары и контент запихнуть в один блок, у которого будет position:relative. Блок с контентом будет просто с маргинами по бокам… посему высота будет регулироваться только блоками с контентом.А сайдбарам можно поставить top:0 и bottom:0 — профит.
Не уверен что блок будет тянуться за сайдбарами — эксперементировать надо. Я обычно такие штуки делал через float и отрицательный маргин.
Вообще схема довольно проста:
У заказчика есть то что он хочет (если есть спека то это вообще шикарно, но так бывает далеко не всегда)
Затем по этим данным составляется первоначальный эстимейт.
затем эстимейт обсуждается с заказчиками, уточняются все нюансы и т.д. Тобиш идет этап согласования проекта.
Затем уже подписывается договор. Тобиш вся эти оценки и прочее — бесплатный труд. Заказчик нужен вам а не вы ему.
скажем так, заказчика не устроила возможность снять с себя права суперпользователя (что я считаю багом). Конечно же подправили и в лайф, инферфейс полностью переписан… но много лишней работы. Собственно мой этот модуль будет ничем иным как просто более мение понятная оболочка для настройки прав. Не более того, никаких велосипедов.
Объект Client должен содержать в себе эдакий API для работы с клиентами. Ну мол добавить, удалить или обновить какие-то параметры. По сути один инстанс этого объекта должен содержать всю информацию о клиенте и все методы для работы с ним. Через контроллер уже будут вызываться эти методы, заполняться данные и т.д. Это дает профит при правках бизнес-логики. Мол поскольку вся бизнес-логика вынесена, то изменять надо только один класс а не всю систему. Зависимостей меньше.
Так же надо постараться сделать так, что бы класс Order понятия не имел о существовании Client или хотя бы знал о нем по минимуму (что он есть и что связь идет через конкретное поле БД скажем...) в случае когда API требует вывод заказов для конкретного клиента.
Как хороший пример ООП структуры советую посмотреть Yii — у этот фреймворка довольно гибкий и в документации хорошо описана архитектура и ее плюсы.
А так вопрос архитектуры довольно сложен, это больше философия или способ мышления. Но толк от ООП больше когда структура классов проектируется так, что бы меньше было зависимостей. Продумывайте юз-кейсы.
Надо бы покалупать этот omniauth… может быть я и погорячился, если не вдаваться в кишки сервисов, то штука полезная ибо избавляет от головной боли с авторизацией через разные сервисы одного и того же пользователя… надо будет изучить по подробнее…
собственно универсальное расширение врят-ли логично делать. Опять же можно сделать что-то типа мультиавторизации с выносом всех сервисов аля facebook или google в отдельные классы, и тогда допилить что-то можно будет. Но в случае vkontakte — только если кто-то прикрутит сам. Основу сделать не сложно, и тут поможет те самые oauth.
К слову если рассматривать платные варианты — это самая лучшая из систем. Правда ее надо грамотно настроить перед испольованием, но зато есть возможность установить весь пакет — Jira + Confluence. В этом случае выйдет именно то что вам надо.
Rights — уже сделан и является одним из самых удачных расширений, ну и мой на подходе. Надеюсь мой имплементация UI вам понравится. Даже может напишу на хабре о процессе написания, если наберусь смелости.
