Мне кажется, было бы удобнее, если бы камера была не встроена в заднюю крышку, а подключалась отдельно тем же usb. Таким образом сам дисплей можно было бы разместить так, как удобно, и независимо настроить вид для камеры.
Если кого то беспокоят функции, то их можно вынести в фабричные методы, например. По логике как раз подходит, раз уж все равно в них только создание объекта. Но с функциями запись короче, я бы сделал и тот и тот вариант, на любителя :)
Хочется более глубокой поддержки фреймворков, в частности Symfony (аннотации, автодополнение во вьюхах, автодополнение вызовов серврисов, доктрины и т.д.). На трекере этот реквест уже достаточно давно.
А в целом молодцы, давно работаю с этой IDE. За такой продукт не жалко заплатить разработчикам!
Не стоит ни pin-код, ни код на телефон, и вот почему: если телефон действительно похитят злоумышленники или недобропорядочные люди то симку выкинут сразу же, а любые коды телефона снимаются достаточно просто. Если же телефон потеряется и его найдут люди, которые захотят его вернуть владельцу, то защита паролем закроет им доступ к справочнику, благодаря которому, они могли бы выйти на владельца телефона…
Думаю, что необходимый уровень гибкости целостной системой достигнуть сложно, придется давать возможность людям ее скорее дорабатывать, нежели настраивать. А для этого необходимо либо изобретать свой внутренний язык программирования, в духе 1С, либо же давать доступ к исходному коду.
Да, с этим понятно. А если не менять код на ходу, а использовать прокси-классы, как делает опять тот же Doctrine? Т.е. генерировать их заранее, класть в папочку и использовать уже от туда. Просто библиотека Ваша конечно же будет многим полезна, но очень сильно мешает компиляция сторонних модулей, в мире shared-хостингов использовать ее будет очень трудно.
Чтение аннотаций хорошо реализовано в Doctrine 2, от туда можно взять все необходимое для работы с ними + новые аннотации так же элементарно создаются. Не требуют компиляции доп. модулей, да и кэширование, по-моему, так уже реализовано. Не смотрели в эту сторону?
Ну это работает и в IDE, в которых поддержка Symfony не заявлена. Тут хотелось бы видеть даже не столько автодополнение методов того или иного сервиса, а автодополнение имен самих сервисов в параметре get(). Нечто подобное реализована в плагине для Eclipse.
А есть где нибудь более подробная информация о поддержке Symfony 2 и Doctrine 2? Что-то кроме автодополненения аннотаций я больше ничего весомого не обнаружил. Хотелось бы видеть продуманную навигацию (переход к вьюшке из экшена, например), автодополнение сервисов ($this->get('..')->..), автодополнение хотя бы стандартных хелперов во вьюхах…
Ну что могу сказать, есть разные задачи с разными условиями. Для нас важна стабильность работы инструмента, по этому мы выбираем xml. Вам важнее кол-во запросов и Вы можете пренебречь стабильностью, выбираете парсинг html. Каждой задаче — свое решение
1. Внимание клиенту и сбой в работе инструментов это все таки немного разные понятия. Я бы лучше улучшал функционал инструмента за это время, чем подстраивал его под разные выдачи.
2. 50 запросов на 30 сайтов… ~1500 позиций отследить руками, ИМХО, не реально каждый день.
3. У нас люди платят за конкретные позиции каждый день. Да и если вдруг позиции резко упадут или поднимутся, будет сразу видно и можно будет предпринять необходимые действия.
1. А если инструментов будет 100? Вы вообще спать перестаните?:) Нет, я считаю, что код должен быть написан так, что бы до минимума сократить возможные внеурочные часы работы над ним
2. Я немного не пойму, зачем Вам 100 IP? У нас висит порядка 30 сайтов в среднем на каждом по 50 запросов мониторим, с учетом того, что поисковые запросы у некоторых сайтов пересекаются, мы можем узнать позицию сразу нескольких сайтов, делаю всего один запрос к яндексу. Таким образом мы спокойно умещаемся в 1000 положенных запросов к яндексу в день.
3. Для нас простой в два дня очень критичен, статистика должна собираться каждый день. От этого зависит сколько клиенты нам заплатят.
Понимаете в чем проблема, html-выдача может внезапно измениться, каптча может внезапно измениться, могут появиться другие способы защиты от роботов, которые Вы не предполагали при написании кода. Т.е. вся система сбора позиций может взять и рухнуть, а Вы в этот момент можете находиться в отпуске, на выходных, спать и так далее. Т.е. все это требует неусыпного контроля. API же предназначен для работы с ним роботами, написав скрипт сбора один раз, его можно повесить в какой-нибудь cron и наслаждаться жизнью. О любых изменениях в правилах выдачи XML Вас предупредят заранее и Вы сможете спокойно внести необходимые изменения, хотя к слову, ни одного такого изменения в XML я не припомню.
А в целом молодцы, давно работаю с этой IDE. За такой продукт не жалко заплатить разработчикам!
2. 50 запросов на 30 сайтов… ~1500 позиций отследить руками, ИМХО, не реально каждый день.
3. У нас люди платят за конкретные позиции каждый день. Да и если вдруг позиции резко упадут или поднимутся, будет сразу видно и можно будет предпринять необходимые действия.
2. Я немного не пойму, зачем Вам 100 IP? У нас висит порядка 30 сайтов в среднем на каждом по 50 запросов мониторим, с учетом того, что поисковые запросы у некоторых сайтов пересекаются, мы можем узнать позицию сразу нескольких сайтов, делаю всего один запрос к яндексу. Таким образом мы спокойно умещаемся в 1000 положенных запросов к яндексу в день.
3. Для нас простой в два дня очень критичен, статистика должна собираться каждый день. От этого зависит сколько клиенты нам заплатят.