В некоторых магазинах позволяют в руках подержать. Даже сделать пару пробных фотографий.
Когда я покупал, мне вообще попался продавец-фотолюбитель… Его специально посылают фотики продавать, т.к. он шарит в них. Его бы мнения я бы послушал.
Короче, можно найти варианты.
1. я не фотограф, а любитель. кое-как фотографировать умею, немного основы знаю, но не более того. взял, чтобы фотографировать семью.
2. перед покупкой взял у знакомых аналогичных фотик, фоткал смотрел что удобно, что не удобно.
брал другие, смотрел разницу по удобству. короче просто выбирал какой лучше в руку ляжет.
PS: Зачет на ответ. Мысль та же, но в более развернутой форме.
И ещё. посмотрите ссылку из моего ответа. там в конце есть интересный список либ. в комментах тоже можно много полезного найти. Вот например из списка либ из статьи:
формы и грид: code.google.com/p/geckotoolbox/
сам я не использовал, но судя по доке, вроде ничего. я бы попробовал… code.google.com/p/geckotoolbox/wiki/Form
по идея, что-то знакомое…
Конкретно в том проекте не меняли.
Да в Zend_Form есть такие моменты, которые сложно обходить.
Если очень сильно нужно, то попробуйте Symfony2 forms в связке с Doctrine ORM.
Эти формы меня гораздо больше радуют. Но как их прикручивать к Zend — вопрос, там некоторые фишки могут сойти на нет (например, когда данные берутся автоматически из реквеста сразу в модель, хотя если помучаться, то и это можно прикрутить). Всё зависит от ваших ожиданий.
я моих проектов пока хватало Zend_Form. Уж не такие там и сложные формы были.
И ещё, килограммы коды писать всё-равно придется. Это же Zend. Там много всяких кубиков разного размера, между которыми нужно писать связки, пусть даже примитивные, но их приходится писать.
Так что совет, увеличивайте трудоемкость. Введите какую-нибудь систему оценки трудоемкости.
мы недавно оценивали в попугаях, получилось более адекватно, чем в человеко-часах.
Идея такая, выбираете какую-нибудь самую простую задачу. Пусть это будет скрипт генерации бреда.
А далее считайте, написание такой-то логики займет 10 скриптов генерации бреда.
Такая оценка получается точнее. пробовали на нескольких разных программистах, все они оценивали так точнее.
так получается потому, что оценивается сразу сложность задачи без прикидки сколько делать. А из сложности сразу следует время автоматом.
Senior — это старший разработчик, его дело не только писать но и знать как надо, а иногда и учить мелких. Оценка трудозатрат — это тоже важно. Набивается на количестве проектов, которые ты сдал.
project manager — это менеджер, возможно бывший программист. Ему сложно адекватно оценить, т.к. он уже далек от этого.
>> должен писать только бизнес логику
это как, можно подробней?
xdebug — да — действительно вещь
>> признаюсь, что очень трудная технология производства через тесты.
да, тяжело себя перестроить. Однако качество кода повышает на порядок. А когда привыкните, то будете писать код быстрее, чем раньше, экономя время на простой отладке.
+ ловить разные сложные ситуации удобно.
например, ситуация:
function test(User $user) {...}
если при вызове функции тест передать туда не объект User, а что-то ещё, то возникнет синтаксическая ошибка. Такие вещи ловятся логикой, в которой надо зашить то, чтобы неправильно функцию test никто не вызывал.
Логику желательно описывать тестами. (читай TDD)
у меня с mysqli_multi_query был глюк, он «глотал» (пропускал) часть запросов посередине строки с пачкой запросов. так что будьте аккуратны, проверяйте, что он сделал.
Ах да, как раз сегодня мучал JPA проект. JPA заставляет программиста мыслить объектами, а не запросами. Поэтому приходится более внимательно относиться к архитектуре кода.
потому чтобы добавить одну фичу, пришлось
либо рефакторить структуру БД
либо писать дополнительную логику.
выбрал первое. код стал лучше и понятней… а логика хорошо разбежалась из одного места по разным классам.
я так работал, оно не всегда удобно.