для небольших компаний когда вы шлете, сотню вторую писем в неделю — согласен.
мы шлем по рассылке больше 100 тыс писем в день с адреса no-reply@, если туда подставить реальный адрес и посадить человека, то он будет получать где-то тысяч 20 писем в день в стиле «ваше сообщение получено, я отвечу как прочту» и прочие атлупы.
сразу встает проблема — одинаковое время кеширования, и переменные в use, и это мы туда еще параметров запросов никаких не передавали.
другая проблема — у нас модели (или просто Query) могут обращаться к разным базам, одним махом уже не покешируешь.
резюмируя: на мой взгляд:
1. текущая реализация подходит для примеров из документации, в реальном проекте обычно код сложнее.
2. появляется реально лапша коллбеков, за что я всегда любил yii — что код получается логичным, читабельным и минимум обвеса. Сейчас же в угоду паттернам клиенский код не удобный. Осталось добавить еще вызов пары фабрик, сервис локаторов и получим симфони или зенд.
3. отладка — иногда удобно пройтись по построению запроса дебаггером и посмотреть потом в самом конце в queryInternal что туда пришло и что оно вернуло, с анонимками — сразу не попадешь в фукнцию, надо идти до call_user_func — эт такое, придираюсь
4. возможно добавление метода cache в Query и не отвечает канонам, паттернам и всего всего такого умного, но по факту оно удобнее и фукнциональнее
Большое спасибо за работу! Пользуюсь второй версией еще с августа 2013.
Очень расстроила функция cache в db\Connection, предыдущие варианты c beginCache и endCache были тоже не фонтан, но использовать было удобнее.
Сейчас же в нужно оборачивать все в анонимные функции, через use() передавать зачастую по несколько штук переменных, а если запросов много идет подряд — то вовсе кучу переменных, как по мне — совсем не по «феншую».
Почему бы не сделать как было в старом добром Yii1 — к query добавляем функцию cache($duration, $dependency = null) — и получается гораздо удобнее и красивее.
мне кажется, что в вашей ситуации нужно не active record на dao (или еще чтото) менять, а сам алгоритм
зачем грузить сразу все записи в память? — чтобы «быстрее работало» что ли?
у меня в системе порядка 1млн подписок, которые каждый день обрабатываются, обработка идет пачками по 1000 штук, германовские скрипты месяцами висят запущенными и не жрут память
не было еще ни одного обзора коптеров, где потом бы в комментариях не писали «15 минут полета — почему так мало?», «почему fpv полеты не в HD качестве, надо просто wifi прикрутить»
немного радует, что велосипедистов со своими фреймворками и без них поуменьшилось (по сравнению с прошлым опросом)
так лет через 10 может и вообще не будет
почитайте форумы FPV, Вы будете наверное даже не 1000 по счету, который предлагает использовать wifi для стримминга видео с модели.
в реальных условиях на расстояние 500 м-2 км весьма будет проблематично это сделать от того и нет wifi для видео в более-менее массовых разработок
первый раз лучше купить два готовых, один про запас, после того как его сломаете — начинать делать свой
преимущество что в готовом все будет сделано более-менее ровно и важно понять сам принцип распложения деталей и т.п.
а потом можно будет и творчеством с рамами заняться
при всем желании, не верю что Meego, тем более Firefox OS вдруг в один момент станет популярнее WP (с и так небольшой долей рынка)
обьем человеко часов который вложен в WP думаю гораздо больше, чем в предыдущие две системы, чудес не бывает, что они вдруг «выстрелят».
99% людей видели эти системы по роликам на ютубе и делают «экспертные» выводы.
мы шлем по рассылке больше 100 тыс писем в день с адреса no-reply@, если туда подставить реальный адрес и посадить человека, то он будет получать где-то тысяч 20 писем в день в стиле «ваше сообщение получено, я отвечу как прочту» и прочие атлупы.
Какой смысл?
НО возьмем пример, в виджете, фукнция run:
задача — как это все закешировать:
вариант 1:
чет дофига анонимок, давайте по другому
вариант 2:
сразу встает проблема — одинаковое время кеширования, и переменные в use, и это мы туда еще параметров запросов никаких не передавали.
другая проблема — у нас модели (или просто Query) могут обращаться к разным базам, одним махом уже не покешируешь.
резюмируя: на мой взгляд:
1. текущая реализация подходит для примеров из документации, в реальном проекте обычно код сложнее.
2. появляется реально лапша коллбеков, за что я всегда любил yii — что код получается логичным, читабельным и минимум обвеса. Сейчас же в угоду паттернам клиенский код не удобный. Осталось добавить еще вызов пары фабрик, сервис локаторов и получим симфони или зенд.
3. отладка — иногда удобно пройтись по построению запроса дебаггером и посмотреть потом в самом конце в queryInternal что туда пришло и что оно вернуло, с анонимками — сразу не попадешь в фукнцию, надо идти до call_user_func — эт такое, придираюсь
4. возможно добавление метода cache в Query и не отвечает канонам, паттернам и всего всего такого умного, но по факту оно удобнее и фукнциональнее
разумеется, ИМХО
а как на счет метода cache в query — чтобы избавиться от анонимных функций?
Очень расстроила функция cache в db\Connection, предыдущие варианты c beginCache и endCache были тоже не фонтан, но использовать было удобнее.
Сейчас же в нужно оборачивать все в анонимные функции, через use() передавать зачастую по несколько штук переменных, а если запросов много идет подряд — то вовсе кучу переменных, как по мне — совсем не по «феншую».
Почему бы не сделать как было в старом добром Yii1 — к query добавляем функцию cache($duration, $dependency = null) — и получается гораздо удобнее и красивее.
зачем грузить сразу все записи в память? — чтобы «быстрее работало» что ли?
у меня в системе порядка 1млн подписок, которые каждый день обрабатываются, обработка идет пачками по 1000 штук, германовские скрипты месяцами висят запущенными и не жрут память
и там же демка для примера со спаршенной статьей приведенной в качестве примера boilerpipe-web.appspot.com/extract?url=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F198982%2F&extractor=ArticleExtractor&output=htmlFragment&extractImages=
так лет через 10 может и вообще не будет
в реальных условиях на расстояние 500 м-2 км весьма будет проблематично это сделать от того и нет wifi для видео в более-менее массовых разработок
преимущество что в готовом все будет сделано более-менее ровно и важно понять сам принцип распложения деталей и т.п.
а потом можно будет и творчеством с рамами заняться
обьем человеко часов который вложен в WP думаю гораздо больше, чем в предыдущие две системы, чудес не бывает, что они вдруг «выстрелят».
99% людей видели эти системы по роликам на ютубе и делают «экспертные» выводы.
я находился на странице, общался с тех поддержкой, они удалили аккаунт, обновил страницу и попал сюда:
длинное горизонтальное меню, походу какаято псевдоадминка, но большинство пунктов не рабочие
зачастую когда садишься за чтото новое, очень полезно пройтись пошагово от index.php хотя бы до экшена контроллера
советую Вам потратить пол часа на изучение и настройку xdebug с Вашей IDE
вместо траты «часов с var_dump» хватит 3 минут пройтись по коду пошагово