AlexPres 4 июн 2013 в 13:05

…

1 мин

13K

Проектирование API * Zend Framework *

+27

Комментарии 26

nekt 4 июн 2013 в 14:17

Что же это за апи такая, что её мониторить через гугл.аналитику проще, чем вставить счетчик в вызов апишки или посмотреть по логам статистику вызовов?

nekt 4 июн 2013 в 14:20

Извиняюсь, перечитал пост, «заказчикам нравится», ага. Но для меня это все равно выглядит несколько странно.

AlexPres 4 июн 2013 в 14:22

Почему странно, на ваш взгляд?

Конечно, сохранять счётчик очень просто, но как потом быть с отчётами по нему?
Одно дело самому писать приложение, да ещё с выбором дат, а другое дело — пользоваться готовым да от Гугла. Я так рассуждал.

nekt 4 июн 2013 в 14:40

Графики, это конечно, хорошо. Но и без гугла их есть достаточно много — знай только, подсовывай им выборку по дням.

А странно оно на мой взгляд потому, что использование API — все-таки больше системная информация, нежели пользовательская. Она почти не коррелирует с посещаемостью сайта, его популярностью, рекламой и позицией в поисковиках. Из этого отчета не вытащить ничего такого, что помогло бы в задаче продвижения, развития и оптимизации сайта. Это все равно, что выводить гугл.аналитику такие графики, как загрузку сервера, количество используемой памяти, свободное место на диске. Я еще понимаю, если бы информация о запросах по api отображалась в какой-нибудь системе мониторинга типа нагиоса. Но вот гугл.аналитика…

AlexPres 4 июн 2013 в 14:59

я вас понял. В этом проекте интересует только частота запросов к API. Как это Nagios-ом мерить?

Ну и сами понимаете, поднять Nagios или прикрутить плагин на PHP — это решения разного калибра.

nekt 4 июн 2013 в 15:09

Так же как и все остальное — графиками. Так-же написать плагин и подключить. Не знаю, правда, насколько конкретно нагиос удастся срастить с подобным отчетом, умеет ли он генерировать показывать графики посуточно или нет. И умеет ли показывать не среднее значение, а суммарное.

А касаемо разного калибра — это скорее проблема выбора инструмента под задачу. С тем-же успехом можно было бы добавить в крон скрипт, который бы генерил статистику по использованию апи и выдавал её в виде таблички с цифрами. Это было бы еще проще, чем подключать аналитику. И калибр у этого решения еще меньше.

hiker 4 июн 2013 в 14:40

Синхронный запрос к Google Analytics может заметно увеличить время ответа API. В приведенном решении неплохо бы указать timeout для запроса к GA, а лучше делать запрос после закрытия соединения (к примеру функцией fastcgi_finish_request в случае использования php-fpm).

AntonShevchuk 4 июн 2013 в 15:15

У GA есть ограничение на объём собираемых данных, если перевалите за лимит (https://support.google.com/analytics/answer/1070983?hl=ru), то тама включаются ограничения, и данная статистика становится не актуальной, погуглите в этом ключе. Ну еще и задержка почти в сутки…

nekt 4 июн 2013 в 15:24

Задержка же вроде лечится ручным выставлением конечной даты отчета на сегодняшний день?

AntonShevchuk 4 июн 2013 в 15:49

Когда объём данных переваливает лимит это уже никак не лечиться… вроде…

mx2000 4 июн 2013 в 15:17

class XXX_Controller_Plugin_Integration_Google_Analytics_Mobile_Tracker

Чужие ошибки никого ничему не учат.

alex4 4 июн 2013 в 15:20

Вас XXX смущает или длинное имя класса?

egge 4 июн 2013 в 20:18

Рекомендую почитать Clean Code — Robert C. Martin

alex4 4 июн 2013 в 21:37

Я читал. Что конкретно?

egge 4 июн 2013 в 21:47

Плохо читал. XXX_Controller_Plugin_Integration_Google_Analytics_Mobile_Tracker — это_пиздец_какое_длинное_название_метода. Ты наверное себя совсем не жалеешь.

alex4 4 июн 2013 в 21:59

Ну это не метод, а класс, во-первых.

Во-вторых, это Zend naming convention, увы.

В-третьих, если почитать ещё и Фаулера, то можно обнаружить, что длинные имена как раз лучше коротких, но снабжённых комментариями.

В-четвёртых, было бы здорово получить дельный комментарий по существу публикации. Р

Ну и — размер не главное :)

egge 4 июн 2013 в 22:13

Ну это не метод, а класс, во-первых.

Прошу прощения, но сути это не меняет

Во-вторых, это Zend naming convention, увы.

Печально

В-третьих, если почитать ещё и Фаулера, то можно обнаружить, что длинные имена как раз лучше коротких, но снабжённых комментариями.

Но не 65 же символов?) И еще, если есть комментарии — это плохой код (если вы читали «Clean Code» тогда знаете почему)

В-четвёртых, было бы здорово получить дельный комментарий по существу публикации. Размер — не главное :)

Я вообще не php программист, зашел почитать сам метод. Но увы такой способ меня не интересует. Скорее всего будем использовать apigee.com

alex4 5 июн 2013 в 08:36

Не стоит бояться длинных имен. Напротив, байты экономить не надо, подробные имена здорово облегчают чтение кода.

отсюда

AndrewStephanoff 5 июн 2013 в 15:56

ZF1 создали ещё до появления namespaces в PHP, поэтому такие длинные имена — это не что иное, как workaround для namespaces. Имя класса в данном случае будет Mobile_Tracker, что, согласитесь, достаточно нормально читается. Начиная с PHP5.3 такого изврата уже нет.