К сожалению, я уже давно не использую Zend Framework и не могу вам помочь. Когда использовал, в Zend ACL еще наследования ролей не было )
Но решение должно быть аналогичное — объявление интерфейса для участвующих объектов и поддержка этих интерфейсов в ACL.
В Limb, например, есть возможность использовать объекты в качестве ролей и ресурсов. Это очень удобно как в описанном вами случае когда объект должен менять роль в зависимости от своего состояния, так и в зависимости от переданного ему ресурса. Смотрите по ссылке: wiki.limb-project.com/2011.1/doku.php?id=limb3:ru:packages:acl
Не пробовали применять следующее решение vagrantup.com/? По сути это набор из ruby-скриптов поверх VirtualBox с интеграцией puppet и chef.
Если пробовали, прокомментируйте пожалуйста.
Серия слоганов с маек codesmack:
TDD: All code is guilty until proven innocent
OpenID: So you need to steal my password only once
He broke the build!
Еще можно воспользоваться цитатами из whatthecommit.com:
Boss made me do it
Ok, 5am, it works. For real.
Уже не помню к сожалению точные описания всех переменных для чего, но они мне в свое время очень помогли при работе из php с oracle (прописываются в .bashrc или по аналогии):
Ну ясного разделения я не увидел, а главное предупреждения что не нужно пытаться начинать с обеими вещами одновременно. Но это мое мнение, за статью спасибо.
Не считаю себя «TDD гурой» :), но попробую ответить.
Во-первых, в этой статье опять допустили классическую ошибку по этой теме: смешали TDD и умение писать юнит-тесты. Это 2 абсолютно разных вещи: TDD — это техника записи тестов перед кодом, юнит-тесты — это юнит-тесты :) Поэтому прежде чем практиковать TDD, научитесь писать юнит-тесты и не пытайтесь делать это одновременно — потратите много усилий и вероятно будете разочарованы. Умение писать юнит-тесты — такой же навык, например, как работа с регулярными выражениями. Вначале тяжело, а потом разбираешься и привыкаешь.
По юнит-тестам: уже рекомендованный выше Ошроув (маст-рид) и более академический Мессарош (xunit test patterns).
По ТДД: обе книги Кента Бека «TDD в примерах» и XP, они обе в сети есть.
Еще по архитектуре рекомендую «Чистый код» Р. Мартина («дядя Боб»)
Во-вторых, написание тестов для legacy-приложений, т.е. тех где в архитектуру не была заложена тестируемость (и у которых обычно отсутствуют тесты) — одна из самых сложных задач, под силу только test-гуру. Об этом почему-то практически все забывают. Если вы только начинаете с тестами — не беритесь за это в одиночку, лучше пригласите наемного специалиста и выделите на это бюджет (деньги/время).
В-третьих, обязательно нужно разделять виды тестов: юнит-тесты (про которые везде пишут), интеграционные тесты и системные тесты (про вторые и третьи намного меньше).
Юнит — все знают, тестируется один класс без внешних зависимостей (файловая система, бд, сеть — это заменяется заглушками). Работают везде, очень быстры, покрывают максимум кода.
Интеграционные тесты — тестируется взаимодействие нескольких классов вместе, по характеристикам обратны юнит-тестам: обычно внешние системы не подменяются, нужна настройка окружения, выполняются намного дольше, покрывают только нужные куски кода.
Системные тесты — тестируют систему сверху донизу, являются выполняемым ТЗ заказчика. Похожие на интеграционные тесты, но затрагивают всю систему, поэтому обычно выполняются еще дольше, сюда также относится тесты UI, внешних сервисов и т.п.
Очень важно разделять тесты в разные папки по типам, иначе они перемешаются и сложности настройки и эксплуатации интегр. и системных тестов убьют желание у разработчиков запускать вообще что бы то ни было.
1. Тесты зависят не от архитектуры, а от требований заказчика. Если — архитектура поменялась, а требования нет — тесты нужно подстроить под новую архитектуру. В плане ТДД — тесты меняются до изменения кода, поэтому «изменение архитектуры» происходит одновременно с изменениями тестов. Смысл ТДД — тесты двигаются чуть впереди кода и все действие идет маленькими шажками.
2. Тестирование элементарных блоков — это юнит, все зависимости подменяются моками. На все их писать необязательно, если метод очень простой (например, обычный геттер/сеттер), то только время убьете. Или у вас есть функция которая выполняет запрос к базе, типа такой:
function getClients($id) {
return $this->db->query("SELECT * FROM clients WHERE id = $id");
}
смысла писать на нее юнит-тест нет, а вот интеграционный — стоит.
Написание тестов до основного кода очень сильно влияет на конечную архитектуру приложения, она сама начинает делиться на слои, что в итоге дает более удобную и гибкую архитектуру.
Основное правило: если вам тяжело писать тест — меняйте архитектуру.
Пишите тесты и все у вас получится :)
FireBug сильно тормозит рендеринг (форм/окон) ExtJS. Попробуйте попользоваться с отключенным файрбагом — производительность уже совсем на другом уровне.
Не знаю что у вас не работает, у меня все вышеприведенные примеры отработали нормально (с соответствующей предыдущей инициализацией переменных, конечно).
Следует также заметить, что при изменении innodb_log_file_size придется остановить сервер и удалить (или переименовать) старый лог файл, для чего могут потребоваться рутовые права. Если же старый файл не удалять, mysql просто откажется стартовать.
Моя выжимка из конфига (не самая сильная dev-машина, 3G RAM, Dual CPU E2140 @ 1.60GHz)
Кстати, за «рекомендуют даже php-программисты» можете нахватать минусов в карму, я-то понимаю, что фраза вырвана из контекста, но кого-то может обидеть :)
И да, рад, что смог помочь :)
Укажите еще один официальный сайт книги, на мой взгляд более интересный: artofunittesting.com/. Стоило бы упомянуть также и остальную «тусовку»: «Майкл Физерс — Эффективная работа с унаследованным кодом» (цитата самого Osherove: «You can learn more… in a book I have found to be worth its weight in gold: Working Effectively with Legacy Code by Michael Feathers», у меня самого, к сожалению, до нее еще руки дойти не успели, но непременно прочитаю), «Джерард Мессарош — Шаблоны тестирования xUNIT», обе книги Кента Бека по экстремальному программированию, вот здесь неплохой пост.
Также из еще непрочитанного, но потенциально интересного:
Steve Freeman, Nat Pryce — Growing Object-Oriented Software, Guided by Tests
Liang Yuxian Eugene — Javascript Testing Beginner's Guide
Эта статья не сравнивает git с svn, а рассказывает об опыте применения git во флэш-разработке.
Если коротко:
1) Скорость. Гит не завязан на сеть и поэтому задержки при выполнении локальных операций практически не ощущаются. Опять же пока не попользуешься не узнаешь, как это было долго при использовании svn.
2) Ну про ветки уже все сказали. В SVN они есть, но большие проблемы при их создании, поддержке а главное слиянии. Еще одно большое отличие — в SVN ветки должны быть глобальными, т.е. существовать в центр. репозитории, а в Git можно иметь кучу локальных о которых никто не знает.
3) Возможность отложить изменения (stash). Очень часто бывает что ты в середине чего-то и не можешь коммитить прямо сейчас, т.к. сломаешь центр. репозиторий (в случае svn), а нужно очень срочно сделать багфикс на новых изменениях других разработчиков. Делаешь git stash и твоя раб. копия снова чиста. Можно обновиться, быстро исправить, закоммитить и накатить обратно свои изменения для продолжения прерванной работы.
4) Есть такая вещь как amending commit — можно исправить предыдущий коммит, добавить в него файлы, изменить сообщение в коммите, как если бы его вообще не было.
И таких вещей еще очень много, я описал только то, что первое пришло на ум.
Из минусов:
1) высокий входной порог
2) сдвиг парадигмы SVN (тут нужно думать по-другому, посмотрите hginit.com/00.html, там про Mercurial, но мысль в целом похожа),
3) много различных команд, хотя для начала нужно всего 3-4
4) мало GUI средств, основная работа идет в консоли, многих это пугает
Извините, но вы не можете сравнивать не попробовав. Нельзя рассуждать о достоинствах езды на автомобиле, если до этого вы ездили только на велосипеде.
Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
Попользуйтесь хотя бы месяц, и вы сами все поймете.
Надо просто себе объяснить, как она работает и все. Я немного переставил аргументы: tar -xvzf <file>
x — сначала действие, я хочу распаковать (eXtract)
v — хочу видеть, как она это делает
z — тип .gz
f <file> — файл с именем <file>.
Т.е. ключи xvzf у меня в мозгу формируются в предложение: «распакуй, чтобы я видел прогресс, архив .gz с именем файла <file>»
По аналогичной схеме запоминается уже и
tar cvzf — создай архив .gz
tar xvjf — распакуй архив .bz2 и т.п.
Но решение должно быть аналогичное — объявление интерфейса для участвующих объектов и поддержка этих интерфейсов в ACL.
Если пробовали, прокомментируйте пожалуйста.
TDD: All code is guilty until proven innocent
OpenID: So you need to steal my password only once
He broke the build!
Еще можно воспользоваться цитатами из whatthecommit.com:
Boss made me do it
Ok, 5am, it works. For real.
Во-первых, в этой статье опять допустили классическую ошибку по этой теме: смешали TDD и умение писать юнит-тесты. Это 2 абсолютно разных вещи: TDD — это техника записи тестов перед кодом, юнит-тесты — это юнит-тесты :) Поэтому прежде чем практиковать TDD, научитесь писать юнит-тесты и не пытайтесь делать это одновременно — потратите много усилий и вероятно будете разочарованы. Умение писать юнит-тесты — такой же навык, например, как работа с регулярными выражениями. Вначале тяжело, а потом разбираешься и привыкаешь.
По юнит-тестам: уже рекомендованный выше Ошроув (маст-рид) и более академический Мессарош (xunit test patterns).
По ТДД: обе книги Кента Бека «TDD в примерах» и XP, они обе в сети есть.
Еще по архитектуре рекомендую «Чистый код» Р. Мартина («дядя Боб»)
Во-вторых, написание тестов для legacy-приложений, т.е. тех где в архитектуру не была заложена тестируемость (и у которых обычно отсутствуют тесты) — одна из самых сложных задач, под силу только test-гуру. Об этом почему-то практически все забывают. Если вы только начинаете с тестами — не беритесь за это в одиночку, лучше пригласите наемного специалиста и выделите на это бюджет (деньги/время).
В-третьих, обязательно нужно разделять виды тестов: юнит-тесты (про которые везде пишут), интеграционные тесты и системные тесты (про вторые и третьи намного меньше).
Юнит — все знают, тестируется один класс без внешних зависимостей (файловая система, бд, сеть — это заменяется заглушками). Работают везде, очень быстры, покрывают максимум кода.
Интеграционные тесты — тестируется взаимодействие нескольких классов вместе, по характеристикам обратны юнит-тестам: обычно внешние системы не подменяются, нужна настройка окружения, выполняются намного дольше, покрывают только нужные куски кода.
Системные тесты — тестируют систему сверху донизу, являются выполняемым ТЗ заказчика. Похожие на интеграционные тесты, но затрагивают всю систему, поэтому обычно выполняются еще дольше, сюда также относится тесты UI, внешних сервисов и т.п.
Очень важно разделять тесты в разные папки по типам, иначе они перемешаются и сложности настройки и эксплуатации интегр. и системных тестов убьют желание у разработчиков запускать вообще что бы то ни было.
1. Тесты зависят не от архитектуры, а от требований заказчика. Если — архитектура поменялась, а требования нет — тесты нужно подстроить под новую архитектуру. В плане ТДД — тесты меняются до изменения кода, поэтому «изменение архитектуры» происходит одновременно с изменениями тестов. Смысл ТДД — тесты двигаются чуть впереди кода и все действие идет маленькими шажками.
2. Тестирование элементарных блоков — это юнит, все зависимости подменяются моками. На все их писать необязательно, если метод очень простой (например, обычный геттер/сеттер), то только время убьете. Или у вас есть функция которая выполняет запрос к базе, типа такой:
function getClients($id) { return $this->db->query("SELECT * FROM clients WHERE id = $id"); }смысла писать на нее юнит-тест нет, а вот интеграционный — стоит.
Написание тестов до основного кода очень сильно влияет на конечную архитектуру приложения, она сама начинает делиться на слои, что в итоге дает более удобную и гибкую архитектуру.
Основное правило: если вам тяжело писать тест — меняйте архитектуру.
Пишите тесты и все у вас получится :)
<?php
$property = 'property';
$object->property = 'property';
$object->dataproperty = 'dataproperty';
$properties = array('property');
$property_obj = new stdClass(); $property_obj->name = 'property';
var_dump($object->$property);
var_dump($object->{'property'});
var_dump($object->{$property});
var_dump($object->{'data'.$property});
var_dump($object->{$properties[0]});
var_dump($object->{$property_obj->name});
echo PHP_EOL, phpversion();
у меня выводит
string(8) «property»
string(8) «property»
string(8) «property»
string(12) «dataproperty»
string(8) «property»
string(8) «property»
5.3.3-1ubuntu9.1
Моя выжимка из конфига (не самая сильная dev-машина, 3G RAM, Dual CPU E2140 @ 1.60GHz)
[innodb]
innodb_buffer_pool_size = 1024M
innodb_flush_method = O_DIRECT
innodb_log_file_size = 256M
innodb_log_buffer_size = 4M
innodb_flush_log_at_trx_commit = 2
innodb_thread_concurrency = 8
[mysqld]
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 1
log-queries-not-using-indexes
default-storage-engine = InnoDB
collation_server=utf8_general_ci
character_set_server=utf8
И да, рад, что смог помочь :)
Также из еще непрочитанного, но потенциально интересного:
Steve Freeman, Nat Pryce — Growing Object-Oriented Software, Guided by Tests
Liang Yuxian Eugene — Javascript Testing Beginner's Guide
Если коротко:
1) Скорость. Гит не завязан на сеть и поэтому задержки при выполнении локальных операций практически не ощущаются. Опять же пока не попользуешься не узнаешь, как это было долго при использовании svn.
2) Ну про ветки уже все сказали. В SVN они есть, но большие проблемы при их создании, поддержке а главное слиянии. Еще одно большое отличие — в SVN ветки должны быть глобальными, т.е. существовать в центр. репозитории, а в Git можно иметь кучу локальных о которых никто не знает.
3) Возможность отложить изменения (stash). Очень часто бывает что ты в середине чего-то и не можешь коммитить прямо сейчас, т.к. сломаешь центр. репозиторий (в случае svn), а нужно очень срочно сделать багфикс на новых изменениях других разработчиков. Делаешь git stash и твоя раб. копия снова чиста. Можно обновиться, быстро исправить, закоммитить и накатить обратно свои изменения для продолжения прерванной работы.
4) Есть такая вещь как amending commit — можно исправить предыдущий коммит, добавить в него файлы, изменить сообщение в коммите, как если бы его вообще не было.
И таких вещей еще очень много, я описал только то, что первое пришло на ум.
Из минусов:
1) высокий входной порог
2) сдвиг парадигмы SVN (тут нужно думать по-другому, посмотрите hginit.com/00.html, там про Mercurial, но мысль в целом похожа),
3) много различных команд, хотя для начала нужно всего 3-4
4) мало GUI средств, основная работа идет в консоли, многих это пугает
Ну да, тут надо крутить педали, а там нажимать на них, какая разница, не вижу особых преимуществ…
Попользуйтесь хотя бы месяц, и вы сами все поймете.
x — сначала действие, я хочу распаковать (eXtract)
v — хочу видеть, как она это делает
z — тип .gz
f <file> — файл с именем <file>.
Т.е. ключи xvzf у меня в мозгу формируются в предложение: «распакуй, чтобы я видел прогресс, архив .gz с именем файла <file>»
По аналогичной схеме запоминается уже и
tar cvzf — создай архив .gz
tar xvjf — распакуй архив .bz2 и т.п.