конечно надо бы на майкрософт в суд подать за такие вещи — это ограничение прав и свобод как по мне. так что я принципиально ставлю на виртуалбокс крякнутую винду, только ради ишаков. Если когда-нибудь будут проверять, то мне не составит труда стереть нужные файлы. Да и думаю в суде отмажусь, если этого не получится. Ведь это же посути глупо — ставить ОС только ради одной программы.
слишком все просто:
— задачи иногда приходится группировать, к примеру есть таск Магазин в нем 10 тикетов на багфиксы;
— на задачу прогер должен ставить сколько времени он потратил на эту задачу;
— нужен фильтр по датам, чтобы было понятно кто, что делал за период;
— на проект добавлять людей — не все люди в компании учавствуют в проекте
— статусовдолжно быть больше — как ми нимум показывающие приоритет
это первое, что пришло в голову
на мой взгляд все намного сложнее. Как говорила моя учительница по математике: «знания добываются либо светлой головой, либо железной задницей». А деньги платятся именно за знания и умения. У меня, к примеру, знания приходят очень тяжело. А другому знания даются очень легко — прочитал пол книги и все понятно и он это уже запомнил, я читать книгу вынужден с листком бумаги и карандашем, иначе ничего не запомню.
вообще тема очень интересная. Вот у нас на работе разгорелся спор, если клиент не требует эстимейтов, должен ли менеджер спускать истимейты программистам? Я за то, чтобы каждый таск истемировался — тога программист будет знать когда его закончить и будет поттягиваться к этому сроку и не будет чувствовать себя так расслабленно. На что менеджеры сказали — что а нафига он нужен, если мы не можем точно поставить эстимейт. Тоесть если в реалии таск сделают за 2 часа а его проистемировали на 4 то программист поставит 4 и 2 часа будет байду бить. В общем тут заколдованный круг.
И еще очень интересно, как налажен процесс в средних веб компаниях, где бы это можно было бы почитать?
а как по мне, так это самый настоящий мужской поступок. поступок труса — изменить своей мечте. Что бы не говорили другие — мы пришли в этот мир творить, а не тянуть лямку. Вообще не понимал никогда довода — что скажет жена. Да муж и жена должы понимать друг-друга и потдерживать во всем. и если мужу хренова на этой работе, то она должна понять его поступок. Как говорится друг в беде не бросит. Да и думал ли тотже Эйнштейн о деньгах, изобретая теорию относительности?
Так что вперед на встречу к мечте!!!
вот вы бы еще поделились как вы визульно сделали управление группами\подгруппами, перемещение юзеров по группам, а также управление правами доступа на тот или иной объект.
да, но это не решает проблему, что приходится хранить id каждого юзера.
$recursive = $this->User->recursive;
$this->User->recursive = 1;
$user = $this->User->read(null, $this->authUser['userid']);
$this->User->recursive = $recursive;
$groups = Set::extract('/Group/id', $user);
тут бы кеш использовать либо еще лучше из сессии дергать а не каждый раз запрос посылать еще и с вложенностью 1.
да и рекурсия сбрасывается после выполнения запроса, так что нет необходимости ее запоминать.
и еще вопрос а вот в строке $permission = Cache::read('Permission_'. Configure::read('App.guestGroup'));
что такое guestGroup?
тоже самое увидел, Но вчера пощупал систему — очень приятная на твердую 5, а сегодня увидел ошибки smarty понял, что система на php написана и так тепло на душе стало.
ну это уже проблема проектирования БД. Не стоит делать широких таблиц — лучше разбить на нексколько. так таблички будут не столь большими и с ними будет проще работать. И если нехватило памяти, то это наверное какой-нибудь cross join был, может запрос был составлен не правильно и join шел не по индексному полю. Когда начинается проект то не всегда известно будет он высоко нагруженный или нет.
по поводу того, что лучше запустить из php несколько запросов или один с JOIN я бы поспорил. При том, что если еще подумать об кешировании запросов и грамотном расставлении индексов.
ACL не совсем удобная система, мы использовали ее в своих приложениях, лишь по тому, что она уже встроена в cakephp, но у нее больше недостатков, нежели достоинств, среди которых:
— сложность понимания (объяснить потом что-то клиенту особенно сложно)
— юзер не может быть в нескольких группах одновременно
— при необходимости ограничения доступа отдельныи юзерам сильно раздуваются таблички (необходимо хранить id каждого юзера )
— отсутсвие кеширования (это конечно не совсем к ACL но сделать кеширование не так просто)
— необходимость делать визуализацию для работы с группами и правами, что не так уж и просто, особенно в случае, если права даются определенной группе лиц.(например, пост могут редактировать создатель, админ и друзья создателя)
я подготовил статью по своей системе кеширования, но похоже, что у меня недостаточно кармы, такчто как наберусь сил — появится еще одна версия системы разделения прав
ну и приоритеты это да
— задачи иногда приходится группировать, к примеру есть таск Магазин в нем 10 тикетов на багфиксы;
— на задачу прогер должен ставить сколько времени он потратил на эту задачу;
— нужен фильтр по датам, чтобы было понятно кто, что делал за период;
— на проект добавлять людей — не все люди в компании учавствуют в проекте
— статусовдолжно быть больше — как ми нимум показывающие приоритет
это первое, что пришло в голову
И еще очень интересно, как налажен процесс в средних веб компаниях, где бы это можно было бы почитать?
хотя я работаю на запад, может у них все подругому
Так что вперед на встречу к мечте!!!
$recursive = $this->User->recursive;
$this->User->recursive = 1;
$user = $this->User->read(null, $this->authUser['userid']);
$this->User->recursive = $recursive;
$groups = Set::extract('/Group/id', $user);
тут бы кеш использовать либо еще лучше из сессии дергать а не каждый раз запрос посылать еще и с вложенностью 1.
да и рекурсия сбрасывается после выполнения запроса, так что нет необходимости ее запоминать.
и еще вопрос а вот в строке $permission = Cache::read('Permission_'. Configure::read('App.guestGroup'));
что такое guestGroup?
— сложность понимания (объяснить потом что-то клиенту особенно сложно)
— юзер не может быть в нескольких группах одновременно
— при необходимости ограничения доступа отдельныи юзерам сильно раздуваются таблички (необходимо хранить id каждого юзера )
— отсутсвие кеширования (это конечно не совсем к ACL но сделать кеширование не так просто)
— необходимость делать визуализацию для работы с группами и правами, что не так уж и просто, особенно в случае, если права даются определенной группе лиц.(например, пост могут редактировать создатель, админ и друзья создателя)