Айтибложек

Отправка GuzzleHttp POST параметров с одинаковыми именами через CURLOPT_POSTFIELDS

2016-04-13T09:16:00.000+03:00

Понадобилось отправлять данные в один сторонний API методом POST. Тривиальная задача, которая потребовала довольно напряженных поисков решения.

Дело в том, что API, c которыми мне часто приходится работать, обычно довольно сложные и реализовать отправку множества разнообразных запросов голым curl крайне непродуктивно. Поэтому я с самого начала решил работать с API через библиотеку GuzzleHttp, которая взяла на себя все вопросы базовой подготовки запросов и их отправки различными способами, в зависимости от метода API. Такой подход позволяет сконцентрироваться на подготовке параметров запроса и главным образом всё, что оставалось для комфортной разработки — прописать соответствия методов HTTP методам API.

Грабли нашлись в тот момент, когда в спецификации API обнаружилось, что в POST-метод надо отправлять данные в формате application/x-www-form-urlencoded, т.е. сформированные так же, как обычно формируются GET-строки параметров. Но при этом все параметры должны иметь одно и то же имя. То есть POST запрос должен был выглядеть примерно так:

param=value1&param=value2&param=value3

Привыкнув к тому, что в подавляющем большинстве систем в POST всегда отдаются параметры с разными именами и достаточно отправить их в виде обычного ассоциативного массива PHP, меня этот формат передачи параметров поначалу удивил, но уже совсем скоро начал серьезно раздражать, т.к. очевидного решения для использования в связке с GuzzleHttp не было ни в голове, ни в гугле. GET-запрос с такой строкой передать проще простого - достаточно лишь собрать строку не через build_http_query, а самостоятельно, ручками. Но с POST такое не прокатывает. Одна из обычных практик отправки POST через GuzzleHttp - это создать клиента, настроенного на нужный адрес метода API, а затем передать ему параметр URI и сам запрос, примерно следующим образом:

$client = new GuzzleHttp\Client(['base_uri' => 'https://foo.com/api/']);

$client->request('POST', $uri, ['body' => $requestArray]);

//или, что то же самое:

$client->post($uri, ['body' => $requestArray']);

Однако все-таки гугл не был совсем бесполезен - было найдено решение, которое позволяет передавать POST в виде строки url-encoded параметров. Общая идея была в том, чтобы передавать данные не в формате miltipart/form-data, а в application/x-www-form-urlencoded. При таком раскладе можно отправить POST'ом предварительно сформированную строку параметров через

curl_setopt($ch, CURLOPT_POSTFIELDS, $fields_string);

Мысль о том, что придется переделывать всё на использование Curl, очень не понравилась - уже была написана большая часть кода, да и отказываться от использования удобной библиотеки совсем не хотелось. Однако надо помнить о том, что GuzzleHttp, как и многие другие компоненты - всего лишь обертка над более-менее низкоуровневыми интерфейсами. Хорошенько покопавшись в коде пакета, я нашел место, в котором устанавливался параметр CURLOPT_POSTFIELDS. В итоге работающее решение нашлось, хотя и является, по сути, хаком (подробнее о вытекающих из этого последствиях читайте в последнем абзаце) и выглядит несколько неуклюжим по сравнению с обычными вызовами, которые я приводил выше:

$client->post($uri, [

   'body' => $requestString,

   'curl' => [

      'body_as_string' => true

],

   '_conditional' => [

      'Content-Type' => 'application/x-www-form-urlencoded'

]);

Когда решение нашлось, стало грустно от осознания того количества времени, которое было потрачено на его поиски. Как, впрочем, всегда бывает, когда оно умещается в пару строчек. Есть подозрение, что такая ситуация встречается редко, но тем не менее, вполне вероятна и еще у кого-то. Именно поэтому я и решил опубликовать работающее решение для тех, кто на эти грабли в будущем наткнется.

На всякий случай добавлю, что версия пакета GuzzleHttp, которую я использовал - 6.2.2. Параметры body_as_string и _conditional не относятся к задокументированным, поэтому в более поздних версиях этот хак может уже не работать. На это также намекает и то, что в прежних версиях работа с подобными запросами была организована немного иначе. Постараюсь обновить здесь информацию, если появится что-то новое.

ВНЕЗАПНО решил поиграть с Canvas

2016-03-21T07:29:00.001+03:00

Если вдруг работаю с примитивами без особой цели, то порой люблю заморочиться генерацией более-менее замысловатых картинок. В этот раз получилось нечто типа камеры Вильсона (хотя без "опадания" треков это больше похоже на результат применения фотоэмульсионного метода, переведенный в позитив %)). Без разнообразия было скучновато, поэтому решил добавить цвет, поперечные штрихи и прочие штуки. Раньше не задумывался, но оказывается, не так-то просто сделать плавный переход цвета от одного к другому по мере рисования трека, если цвет надо генерить в шестнадцатиричном формате, как в CSS (а здесь для каждого трека цвет задается индивидуально). И поперечные штрихи на треках меня долго не удовлетворяли своей недостаточной перпендикулярностью к треку. Пришлось даже вспоминать тригонометрию, — но обошлось в итоге без нее.

Код, конечно же, тут просто так не разместить. Поэтому сохранил на jsfiddle.

Пиши код блять!

2013-12-17T18:56:00.003+04:00

Сегодня я расскажу вам об уникальной методологии разработки ПО. Уверяю вас, она произведёт настоящую революцию в нашей индустрии. Почему? Да потому что она разительно отличается от тех теорий, которыми вас досыта накормили заумные книжки и дурацкие статьи в интернетах. Существующие методологии заставляют вас запоминать сотни баззвордов, высчитывать какие-то непонятные метрики или даже (о ужас!) предлагают пустить работу на самотёк и сделать вашу команду самоорганизующейся.

Наша методология гораздо проще и эффективнее. Она предлагает вам сконцентрироваться всего на одной, но очень важной вещи (чтобы случайно не забыть, на какой именно, мы даже вынесли эту вещь в название методологии). Итак, встречайте: инновационная методология разработки под названием…
Пиши код блять!

Именно так. Пиши код блять!

Как мы добавляем фичи в проект? Мы блять пишем код!

Как у нас поставлено тестирование? Мы блять пишем автотесты!

Как мы умудряемся поставлять релизы в срок и в рамках бюджета? Мы блять пишем код качественно и быстро!

Почему наши программисты счастливы и с удовольствием ходят на работу? Потому что они блять пишут код и не отвлекаются на всякую херню!

Конечно, на деле не все так просто, Одной идеи совершенно недостаточно для того, чтобы перестроить всю вашу команду. Поэтому вот вам пошаговая инструкция для внедрения нашей замечательной методологии:

    Выпишите список всей той хрени, которая должна входить в ваш продукт
    Реализуйте всю эту хрень путем блять написания кода
    Протестируйте написанное
    Если что-то работает неправильно — то напишите блять правильный код!

После п.4 немедленно переходите к п.1. Повторять до достижения необходимого результата.

Здорово, правда? Помните, что написание кода — это блять самая важная вещь во всём процессе разработки! А все прочие идеи, которые вы могли видеть в конкурирующих методологиях, я предлагаю подытожить вот таким принципом:

Менеджер, твою мать, облегчи жизнь программисту!

Чтобы программисты могли блять писать код, менеджеры, мать их, должны по возможности облегчать программистам жизнь. Менеджер, мать его, должен делать всё возможное, чтобы код блять писался хорошо: отслеживать процесс написания блять кода, заботиться о том, чтобы заказчики вовремя платили за всю написанную нами хрень, и (самое главное!) вовремя пополнять запасы чая и блять печенек.

Короче говоря: менеджер, мать его, должен заниматься всем, что напрямую не относится к написанию блять кода.

Подробная пошаговая инструкция для, мать их, менеджеров, выглядит следующим образом:

    Понять, что вообще хочет заказчик, и рассказать об этом программистам
    Сделать всё, чтобы программистам было блять комфортно писать код
    Если тот код, что мы блять написали — это не совсем то, что хочет заказчик, то нужно снова сказать об этом программистам

Уверяю вас, эта новая методология изменит жизнь вашей команды. Я искренне верю в неё и считаю её единственно правильной. Почему? Да потому что в нашей индустрии есть только одно действительно важное занятие: писать код блять!

http://factorized.tumblr.com/post/4180288873/programming-motherfucker

Я не джавист, но считаю, что это круто.

2013-06-20T16:23:00.001+04:00

2013-04-29T16:43:00.001+04:00

2013-04-16T13:45:00.003+04:00

Хрен с ним, со смыслом, — главное, код красиво написан. Интересно было бы еще и на sorted() посмотреть )

Полезный скриптик для Chrome Gestures

2012-11-19T05:04:00.000+04:00

В интернете порой попадаются своеобразно сверстанные сайты, в дизайне которых отсутствуют ссылки постраничной навигации вроде "← Назад | Вперед →" и т.п. Однако эти сайты иногда интересны настолько, что я мирюсь с необходимостью постоянно клацать в адресную строку и менять цифру, означающую номер страницы, чтобы попасть туда, куда нужно.
Но рано или поздно это надоедает (а в последнее время я видел немало таких сайтов на tumblr'e) и хочется упростить себе жизнь. Раньше, когда браузером для серфинга у меня был лишь Firefox, я пользовался в таких случаях расширением All-in-One-Gestures, которое имеет функцию "Increment/decrement digit in URL", срабатывающую при выполнении мышью определенного жеста и меняющую последнюю цифру в адресе страницы автоматически.
Теперь же, когда для серфинга я очень часто использую Chrome и соответствующее расширение для жестов — Gestures for Chrome, мне захотелось иметь подобный функционал и в нем. Плагин сам по себе эту функцию не предлагает, однако в нем имеется возможность использовать пользовательские скрипты. Собственно, после того, как я захотел иметь такую штуку, оставалось только придумать удобные жесты и назначить им следующие коды:

m=/(.*\D[0]*)([\d]+)(.*)/g.exec(location.href);if(m)document.location=m[1]+(~~m[2]-1)+m[3];

m=/(.*\D[0]*)([\d]+)(.*)/g.exec(location.href);if(m)document.location=m[1]+(~~m[2]+1)+m[3];

Возможно, кому-нибудь такая штука также пригодится.

UPD: кстати, ничто не мешает эти же скрипты использовать в виде обычных букмарклетов - достаточно создать закладки, вместо URL у которых указать вышеприведенные скрипты, только в URL вместо http:// указать протокол javascript:, чтобы получилось

javascript:m=/(.*\D[0]*)([\d]+)(.*)/g.exec(location.href);if(m)document.location=m[1]+(~~m[2]+1)+m[3];

Yii: динамическое отключение профилирования заросов

2012-11-13T23:14:00.000+04:00

Столкнулся в Yii с проблемами выделения памяти процессам, в которых осуществляется большое (измеряемое десятками тысяч) количество запросов к базе данных.

При включенном профилировании каждый запрос попадает в лог профайлера (а порой и не одного). При этом лог не очищается, пока процесс не будет завершен. В результате с каждым запросом увеличивается количество памяти, потребляемое приложением и в итоге мы вылетаем с ошибкой выделения памяти

Чтобы побороть это дело, не отключая профайлинг в принципе (например, через конфиги), можно сделать такой финт ушами:

function dummyFunction(){
 //выключаем все используемые логроуты в начале
 foreach(Yii::app()->log->routes as $route){
  $route->enabled = false;
 }

 //цикл, в котором происходят многочисленные обращения к БД.
 foreach(.....){
  ......
 }

 //включаем логроуты обратно
 foreach(Yii::app()->log->routes as $route){
  $route->enabled = true;
 }
}

По идее, можно отключать только те логроуты, что профилируют запросы, но использованное упрощение в моем случае оказалось вполне допустимо.

Гопопрограммирование )))

2012-10-26T02:24:00.000+04:00

Если бы Остап Бендер жил в наше время...

2012-09-27T18:47:00.000+04:00

2012-09-14T11:47:00.002+04:00

2012-07-19T22:16:00.001+04:00

А вот какие такие исторические причины позволяют передавать параметры в функцию PHP implode() в любом порядке?

2012-07-06T11:12:00.000+04:00

Чего-то я не догоняю, или blogger не может транслировать RSS отсюда в Feedburner, при этом показывая ссылку на него же. Изврат, конечно, но что делать, если поток уже давно на Feedburnere висит?

Надоело переезжать

2012-06-29T10:23:00.001+04:00

По запросу "Экспорт контента в Blogspot" и им подобным гугл вываливает ссылки на опыт чуваков, которые отсюда слились на Wordpress и т.п. А я вот решил, наоборот, со стандалона соскочить: грустно мне в том бложике как-то было.
Хотя, конечно, не бог весть какое событие. Посмотрел внимательно на то, что стоит со старого блога перекидывать в новый - оказалось, что кроме нескольких записей и хохм ничего переносить-то и не требуется. В итоге перенес вручную пару десятков записей и готово. Заодно не только ноосферу от неактуальной и малозначимой информации почистил, но и себя избавил от необходимости ее содержать.

А переезжать и в самом деле пришлось слишком много, в том числе и в реале. Последний переезд прямо эпичный получился. Сам по себе не слишком масштабный, но двухмесячный подготовительный ремонтный период доставил - скиллы успел прокачать почти по всем рабочим специальностям, кроме каменной кладки и кафельной укладки.
Такие вот события, в общем. А старому бложику - Rest In Peace.

2012-06-29T06:43:00.000+04:00

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

Кэширование ORM в Kohana

2011-12-13T07:45:00.000+04:00

Потратил много времени на обнаружение неочевидной особенности поведения системы кэширования объектов, получаемых из базы с использованием встроенной системы ORM Kohana в случае, если в свойствах модели не указано явно название таблицы, ей соответствующей.

Если вы инициализируете значение $_table_name ORM-модели в ее конструкторе (как в примере ниже):

class Model_Foo extends ORM
{
protected $_db = 'default';
protected $_primary_key = 'id';
protected $_primary_val = 'name';
...
public function __construct($id = NULL)
{
$this->_table_name = 'foo_table';
...
parent::__construct($id);
}
...
}

, то при попытке загрузить закэшированные данные с помощью конструкции вида:

   $foos = ORM::factory('foo')->cached(7200)->find_all();

вы получите, увы, вовсе не закэшированный результат, а вполне себе актуальные данные (которые, конечно же, будут получены ценой запроса к БД, которого вы хотели избежать)

Такое поведение Kohana обусловлено тем, что при чтении объекта из кэша и его последующей корректной десериализации подгружается файл с описанием класса вашей модели Model_Foo, однако его конструктор не вызывается и, соответственно, имя таблицы не инициализируется. Так как поля таблицы в модели не описаны, Kohana пытается загрузить список полей из таблицы, соответствующей названию модели в множественном числе - для примера выше это `foos`. Если такой таблицы в базе данных не находится, то генерируется исключение, которое интерпретируется системой кэширования как признак поврежденого кэша и обрабатывается втихую - возвращая NULL вместо данных. В результате данные загружаются каждый раз из базы данных, несмотря на то, что присутствуют в кэше.

Таким образом, явное указание $_table_name необходимо в тех моделях, выборки для которых вы хотите хранить в кэше и успешно доставать оттуда же.

Хочу особенно отметить, что при загрузке и десериализации объекта из кэша Kohana для него не вызывается автоматически конструктор. Это необходимо учитывать и инициализировать свойства (которые при обычной загрузке устанавливаются в конструкторе) при обращении к методам загруженного из кэша объекта, если они (методы) эти свойства используют.

UPD: как мне подсказали знающие люди на форуме Kohana, если в модели вместо метода __construct() использовать метод __initialize(), описанных проблем при десериализации не возникает, так как этот метод, в отличие от конструктора, в данной ситуации вызывается.

Почты псто

2011-12-07T07:54:00.000+04:00

>ping почта.рф

Обмен пакетами с почта.рф [91.215.36.43] с 32 байтами данных:
Мужчина, вы что не видите, что у нас обед.
Мужчина, вы что не видите, что у нас обед.
Мужчина, вы что не видите, что у нас обед.
Мужчина, вы что не видите, что у нас обед.

Статистика Ping для 91.215.36.43:
Пакетов: отправлено = 4, получено = 0, потеряно = 4
(100% Обед)

via

Сортировочные танцы

2011-09-13T06:59:00.000+04:00

Только что нашел в своей кучке ссылок по названием "Read it later" ссылку на канал отличных музыкально-танцевальных визуализаций различных алгоритмов сортировки. Жалко, что пока на нем всего представлены не все алгоритмы и не все народные танцы европейских народов. Будем надеяться, что на канале появятся и другие разновидности сортировки. Особенно интересно посмотреть, как долго будут продолжаться самые неэффективные ) Ну а пока можно посмотреть те, что уже есть на этот момент:

Пузырьковая сортировка:

Быстрая сортировка:

Сортировка слиянием:

А также сортировка Шелла, сортировка выбором и сортировка вставками:

Спасибо Максиму Оранскому за то, что поделился позитивчиком!

Не будьте велосипедистом!

2011-05-31T07:02:00.000+04:00

Много раз я сталкивался со старыми проектами, написанными в рамках парадигмы программирования, широко известной в узких кругах, как "свой велосипед".

Вот и сейчас, переписывая огромную часть движка сайта, которым пользуется много людей и который нельзя просто так выбросить и написать заново с нуля, я не могу отделаться от мысли, что "свой велосипед" - большое зло. Особенно когда пишешь его и знаешь о том, что ты - не последний, кто над ним будет работать.

Избегайте "своих велосипедов", пожалуйста. Облегчите себе задачу и используйте хотя бы фреймворки. И будьте критичны к своей работе - позаботьтесь о том, чтобы ни фреймворк, ни ваша работа тоже не были "велосипедом".

Иначе ваши преемники будут интенсивно портить вам карму и истекать кислотой в ваш адрес.

Замечательный пример программистского юмора

2010-12-27T07:11:00.000+03:00

if(strpos($_SERVER['HTTP_USER_AGENT'],'MSIE 6')!==false){ die("Die! Die! Die!"); }

via

Скоро на дисплеях страны: трагикомедия «.NET против Java»

2010-06-29T07:16:00.000+04:00

Минутка юмора: нашел очень веселый трейлер про эпические драмы между отцами и детьми-программистами. Доставляет обилие пародий и мелких деталей, которые не всегда заметны с первого раза.

Получил массу удовольствия от просмотра и вам рекомендую :)

Nginx и SVN (405 Not Allowed)

2010-06-22T07:19:00.000+04:00

Установил Subversion на сервере под управлением apache+nginx в виртуальный подкаталог /svn

Настроил, работает и крутится. Но не полностью — никак не коммитятся файлы с картинками, имеющими разрешение png, jpg и т.д. При этом svn ругается следующим образом:

Commit failed (details follow):
Server sent unexpected return value (405 Not Allowed) in response to PROPFIND
request for '.......'

Долго колупался, но все-таки нашел на каком-то заброшенном форуме вопрос про такую же ситуацию и упоминание, что если в конфиге nginx отредактировать строчку

location ~* ^.+\.(jpeg|jpg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js|djvu|mht|chm)$ { ...

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

Вместо этого надо исключить виртуальный подкаталог svn из обрабатываемых nginx'ом каталогов. За это отвечает секция nginx.conf примерно следующего вида:

location ~* ^/(awstats|myadmin/|svn/) {
proxy_pass http://xx.xx.xx.xx:8080;
proxy_redirect http://yoursite.com:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}

После этой правки проблемные файлы отправляются в репозиторий, как по маслу.

В тихом омуте черти водятся

2010-04-21T07:22:00.000+04:00

Тихо-то как...
А черти-то, — они здесь, не спят.
Кто не в курсе — лучше даже и не спрашивайте :)

Форум русского Pligg переехал на новый адрес

2010-02-03T07:24:00.000+03:00

Я окончательно отключил обсуждения Pligg на этом сайте. Увы, времени на сколько-нибудь значимое развитие русской версии этой CMS у меня сейчас совсем нет. Однако я рад, что моя работа не осталась совсем без хозяина и продолжает развиваться. Дело передано в надежные ~~зубы~~ руки Vampir'а и теперь форум, посвященный русскому Pligg находится здесь: cmspligg.ru.

Кто был зарегистрирован на здешнем форуме, смогут зайти на новый под своими именами, запросив там восстановление пароля. Кто не успел - регистрируйтесь с нуля :)

Суровые финские программисты жгут :)

2010-01-11T07:25:00.000+03:00

Ребята из финского подразделения Intel отжигают. Я все чаще радуюсь тому, что программисты - вовсе не скучный народ. По крайней мере, пока они не заняты непосредственно программированием :)

via