Pull to refresh

Comments 45

UFO just landed and posted this here
можно пример правильной «ручной» реализации? без использования фреймворка?
function render($template, $data)
{
extract($data);
ob_start();
require $template;
return ob_get_clean();
}


Шаблон пишется на чистом PHP.
мои статьи по SQL набирали 6к/9к/5к просмотров, у этой статьи всего 1.7к, не очень то люди и заметили, а кто заметил, тот влепил минус — как это принято ни кто не смотрел исходники выложенные на гите, и приняли код приведённый в статье за чистую монету, отсюда эти… не обоснованные обвинения в «лапше», в проекте вообще 4 файла:
  1. moysklad_routine_library — планировалась библиотека функций, по факту вышло что можно было обойтись всего тремя, хотя они общие для клиентской и серверной части, так что всё равно надо было выносить в отдельный файл.
  2. moysklad_customer_order — клиентская часть — смесь модели и фронтэнда, мне кажется для одностраничного сайта вполне допустимо, при чём файл явно делитьсян а две части — сначала PHP с подготовкой данных, затем html с выводом — «смешение» php c html чисто формальное.
  3. moyskald_add_order — серверная часть.
  4. moysklad_curl_details — файл с параметрами API и аутентификации.

на мой вкус мухи отдельно, котлеты отдельно.

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

Единственный человек по делу написал это ilyaplot — ещё раз спасибо.
Очень жаль что ни кто не прокомментировал проблему с пустым POSTом но «полным» — php://input

такое резюме по отклику на статью.
ЗЫ
нет что бы поржать вместе со мной, зачем то обосрали, видимо потребность в «срать» имеет приоритет над «ржать» :)
мои статьи по SQL набирали 6к/9к/5к просмотров, у этой статьи всего 1.7к, не очень то люди и заметили, а кто заметил, тот влепил минус

Судя по рейтингу и комментам, ваши статьи по SQL тоже мало чего полезного содержат. Раз у этой статьи минусов больше, то может и полезного в ней меньше?


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

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


планировалась библиотека функций, по факту вышло что можно было обойтись всего тремя, хотя они общие для клиентской и серверной части, так что всё равно надо было выносить в отдельный файл.

Воот. А потом в рабочем проекте добавятся еще 100500 глобальных функций, и окажется, что неплохо было бы их еще разделить — работа с curl, с массивами, с валютой и т.д. Так может сразу использовать классы и пространства имен?


«смешение» php c html чисто формальное

Оно очень даже тесное, так как у вас нет HTML-разметки, она выводится в строках PHP-кодом, с соответствующими слэшами возле кавычек.


но у людей голова ломается от отсутствия классов, от отсутствия автозагрузчика, видимо когда то им за это хорошенько досталось

Почему вы так уверены, что люди не писали без классов и автозагрузчика? Как раз писали, и знают, к чему это может привести.


Очень жаль что ни кто не прокомментировал проблему с пустым POSTом но «полным» — php://input

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


нет что бы поржать вместе со мной

Ни в вашей статье, ни в ваших комментах с негативным отношением к окружающим нет ничего смешного.

По коду. И нет, отмазка "это же тестовое задание, тут надо просто чтоб работало" не прокатит. Его дают не за этим, а как раз наоборот — чтобы проверить, как вы пишете код.


— Неправильно расставлены скобки, пробелы и отступы. PHPStorm, о котором вы говорили ниже, вам видимо не очень помогает. Имена переменных и фукнций не соответствуют их цели — например, $сounterparty это массив, а название в единственном числе.


echo 'Доступные контрагенты:<br />';
Зачем вы пишете разметку в строках? Вам лень тег php закрыть?)


'<label for="' . $personId . '">' . $person['name'] . '</label>'
Потенциальная XSS-уязвимость. Что если кто-нибудь заведет контрагента с названием "<script>[jscode]</script>"?


$counterpartyId = $counterpartyIdCollection[FIRST_INDEX];
Зачем вы отправляете массив, если вам нужен только первый элемент? Также зачем-то проверяются data-organization-type и data-counterparty-type, хотя они везде установлены в "1".


contentType: 'application/json; charset=utf-8'
Вот и ваша проблема с POST. PHP не принимает данные в формате JSON (документация). Надо убрать contentType, jQuery сам подставит правильный, данные отправлять через $('#orderForm').serialize(), и поменять обработку на сервере, потому что данные сериализуются немного в другом формате.


— Работа функции getNomenclature() не соответствует названию. Ее результат полностью зависит от того, что мы вызывали до нее, так что может вернуть и nomenclature и order и все что угодно. Надо перенести установку URL в нее, и в остальных функциях аналогично. А можно и в класс объединить, тогда снаружи вместо этого


$curl = setCurl(
    $curl,
    $apiSettings[MOYSKLAD_API_URL] . $apiSettings[MOYSKLAD_GET_JURIDICAL_PERSON],
    $apiSettings[MOYSKLAD_GET_JURIDICAL_PERSON_METHOD]);
$persons = getJuridicalPerson($curl);

$curl = setCurl(
    $curl,
    $apiSettings[MOYSKLAD_API_URL] . $apiSettings[MOYSKLAD_GET_COUNTERPARTY],
    MOYSKLAD_GET_COUNTERPARTY_METHOD);
$counterparty = getCounterparty($curl);

$curl = setCurl(
    $curl,
    $apiSettings[MOYSKLAD_API_URL] . $apiSettings[MOYSKLAD_GET_NOMENCLATURE],
    MOYSKLAD_GET_NOMENCLATURE_METHOD);
$nomenclature = getNomenclature($curl);

будет вот так


$apiClient = MoySkladApiClient::create();

$personList = $apiClient->getJuridicalPersonList();
$counterpartyList = $apiClient->getCounterpartyList();
$productList = $apiClient->getProductList();

Все просто и понятно.


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

$сounterparty это массив, а название в единственном числе
— я устал от множественных чисел, приписок array collection list и т.п., больше не практикую.
Зачем вы пишете разметку в строках? Вам лень тег php закрыть?)
видимо
Потенциальная XSS-уязвимость. Что если кто-нибудь заведет контрагента с названием ""?
контрагентов заводит владелец аккаунта, хочет себе в ногу выстрелить — сколько угодно, хотя я думаю разработчики API такую возможность уже исключили
Зачем вы отправляете массив, если вам нужен только первый элемент?

если всё можно обработать по одной технологии то зачем придумывать две? я ни когда не ставлю перед собой цели оптимизации с выгадыванием миллисекунд
Вот и ваша проблема с POST. PHP не принимает данные в формате JSON (документация). Надо убрать contentType, jQuery сам подставит правильный, данные отправлять через $('#orderForm').serialize(), и поменять обработку на сервере, потому что данные сериализуются немного в другом формате.

спасибо огромное, за это вам можно все наезды простить :)
Работа функции getNomenclature() не соответствует названию

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

спасибо, ваш разбор полётов был одной из целей этой публикации
я устал от множественных чисел, приписок array collection list и т.п., больше не практикую.

Вам сложно будет пройти тестовое задание с таким подходом. Никому неохота разбираться в особеностях названий чужого кода.

контрагентов заводит владелец аккаунта, хочет себе в ногу выстрелить — сколько угодно, хотя я думаю разработчики API такую возможность уже исключили

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

если всё можно обработать по одной технологии то зачем придумывать две? я ни когда не ставлю перед собой цели оптимизации с выгадыванием миллисекунд

А оптимизация здесь ни при чем, это банально лишний код.

// было
var $radio_field = $('#orderForm :input:radio:checked');
$radio_field.each(function() {
    var this_val = $(this).val();

    var is_it_counterparty = $(this).data('counterparty-type');
    var is_it_organization = $(this).data('organization-type');

    var may_assign = (this_val > 0 || this_val != '');

    if (may_assign && is_it_counterparty > 0) {
        counterparty[this.id] = this_val;
    }
    if (may_assign && is_it_organization > 0) {
        organization[this.id] = this_val;
    }
});

// стало
var organization = $('#orderForm :input:radio:checked[name=organization]').attr('id');
var counterparty = $('#orderForm :input:radio:checked[name=counterparty]').attr('id');

(полная версия)

соответствует, предполагалось, что вернётся чёрти что и это надо будет как то парсить

Вы не поняли. getNomenclature() просто выполняет запрос с текущими настройками curl (и кстати ничем не отличается от getCounterparty(), у них абсолютно одинаковый код). Если я перед ее вызовом установлю другой URL, то вернутся другие данные, с номенклатурой не связанные.
и кстати ничем не отличается от getCounterparty()

отличается, в контрагентах из полученного массива сохраняются только 'rows', в номенклатурах такой обработки нет, она идёт снаружи метода.
var organization = $('#orderForm :input:radio:checked[name=organization]').attr('id');

мне бы ваши познания в jquery :)
Вам сложно будет пройти тестовое задание с таким подходом. Никому неохота разбираться в особеностях названий чужого кода

у этого тестового была цель выполнить в оговоренный срок, а не качественно написать, у меня отведённое время ушло на «борьбу» с PHP по обработке $_POST, от которой пришлось отказаться и на работу с jquery, на то что бы причесать код времени не осталось

задание принимал бизнес-аналитик / проджект менеджер который собирает команду фрилансеров, ему в срок важнее, качества кода он не оценит.
отличается
Да ну?) moysklad_routine_library.php
function getCounterparty($curlObject)
{
    $response = curlExec($curlObject);
    $data = json_decode($response, true);
    $result = $data['rows'];
    return $result;
}

function getNomenclature($curlObject)
{
    $response = curlExec($curlObject);
    $data = json_decode($response, true);
    $result = $data['rows'];
    return $result;
}

И суть не в этом, а в том, что они не делают то, что отражено в названии. Если я просто вызову getCounterparty(), я не получу никакой сounterparty.

на то что бы причесать код времени не осталось

Для статьи код можно было причесать, при ее написании вас никто не торопил.

ему в срок важнее, качества кода он не оценит

Качество оценит команда фрилансеров, которые будут с вами работать. И читатели статьи.

мне бы ваши познания в jquery :)

Тут достаточно уметь гуглить, «jquery select by name» и «jquery get id attribute». Хотя не вижу принципиальных отличий от ваших селекторов.

Если вы не знаете PHP и jQuery, зачем тогда писать обучающие статьи.
Для статьи код можно было причесать, при ее написании вас никто не торопил

мои обстоятельства меня торопили, на статью ушло около 4-х часов, это пол воскресения, а ещё надо был она работе выправить ножки на материнке, в подъезде организовать установку замка на чёрный ход в подъезд и вообще могу я в воскресение отдаться безделью?
Тут достаточно уметь гуглить, «jquery select by name» и «jquery get id attribute». Хотя не вижу принципиальных отличий от ваших селекторов.

принципиальное отличие межу мои и вашим вариантами только в опыте автора решения в использовании jquery
Если вы не знаете PHP и jQuery, зачем тогда писать обучающие статьи

«на пять не знает даже Бог», если что. Код решает задачу, и я в статье объясняю технологию решения, чем не обучение, учу плохому? вы внесли свою лепту что бы статья стала учить хорошему :)
вообще могу я в воскресение отдаться безделью

Можно было вообще статью не писать, было бы больше свободного времени) И вы думаете, у других авторов нет своих дел? Тем не менее, они уделяют внимание коду, который будут читать другие.


принципиальное отличие межу мои и вашим вариантами только в опыте автора решения в использовании jquery

jQuery и опыт тут ни при чем. Если бы вы хотели получить одно значение, а не массив, вы бы поискали информацию и нашли решение. Тем более что это первые ссылки в гугле.


Код решает задачу, и я в статье объясняю технологию решения

Вот как раз не объясняете, а говорите "я не знаю" и "я не разобрался".


учу плохому? вы внесли свою лепту

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

Тем более что это первые ссылки в гугле.

у Гугла поисковая выдача заточена под пользователя, у когото это первая десятка записей, у кого то не первая, я по jQuery раз в пол года ищу, у меня всякая фигня в первой десятке.
Вот как раз не объясняете, а говорите «я не знаю» и «я не разобрался».

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

Пишите хорошие, а то приходиться писать плохие — свято место пусто не бывает :))
UFO just landed and posted this here

Ваши отмазки выглядят глупо. Думаю, программист смог бы отличить фигню от нефигни, да и вообще найти ответ на такой простой вопрос. Значит вы и не пытались искать. И да, проверил через VPN и анонимайзер в приватном окне браузера и в Internet Explorer, которым не пользуюсь. И в google и в yandex и даже в bing есть нужные ссылки.


Про работу с API написано в документации к API. Зачем делать статью с точно такой же информацией? Может ценность как раз и должна быть в коде для работы с ним?


Отсутствие хороших статей по API Мой Склад не означает, что надо обязательно писать плохие. А если решили написать, то тогда не возмущайтесь на минусы.

После «Я не знаю что такое cUrl» я перестал читать…
логин и пароль в конфиге, конфиг называется moysklad_curl_details.php.
зачем мне psr-4 в проекте на две функции? накидано всё в файл moysklad_routine_library.php, зачем огород городить с psr-4?
С psr-2 есть расхождения?

https://github.com/guzzle/guzzle — посмотрим, спасибо.
странный конфиг.
зачем мне psr-4 в проекте на две функции?

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

про psr1/2/3 как бы нету замечаний? как бы я обычно в рамках общепринятых стандартов «творю».
про psr-2 — используйте http://cs.sensiolabs.org/
psr-3 это про логгирование, что-то у вас я там ничего такого не увидел
тут не завихрения, а просто будет не лапша и возможность отделить мух от котлет
это как раз «про тестовое задание» — потому что в таком виде мало кто посчитает что оно выполнено.
да логирования нет, psr-1/psr-2 обеспечиваются phpStorm / Code / Reformat не так ли? или «cs.sensiolabs.org» способен на большее?
UFO just landed and posted this here
мне показалось что это XML вариант?
UFO just landed and posted this here
не стояло задачи разработать API, но если бы что то уже было кем то разработано, то конечно было бы глупо не использовать, а взять за основу xml вариант и переделать его в json… надо сначала в коде разобраться, потом брать, мне кажется по времени такой подход не укладывается в два вечера после рабочего дня.
UFO just landed and posted this here

Статья с пометкой "tutorial" и с кучей всяких "я не знаю" и "я не разобрался"? Вы серьезно?

вы считаете пометка how_to подойдёт больше?

Я считаю, что статьи такого уровня вообще не стоит писать. Тем более в качестве руководства для других.

я бы подобные статьи с удовольствием читал если бы их кто то их писал, особенно я был бы рад им в поисковой выдаче Google, это лучше чем изобретать очередной велосипед, но мало кто такие элементарные вещи разжёвывает, потому что всем и так всё ясно.

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


Это не велосипед, а тестовое задание. Документация на API есть, учебников по PHP хватает. Получается, вы хотели бы не думать головой при выполнении тестового задания, а просто скопипастить готовое решение? Может цель задания и была в том, чтобы проверить, как вы сами организуете код для работы с таким API.

в работе не надо разрабатывать то что кто то уже разработал, не надо тратить время на то что бы разобраться с чужим кодом, если этот код работает без нареканий, надо тратить время на решение задач а не на проверку «инструментов», если что то работает, то надо этим пользоваться, а не разбирать по винтикам, что бы удостовериться что все винтики живые, ни один не разболтался и резьба ни где не сорвана. Разработка это умение комбинировать инженерные решения, а не умение потратить рабочее время на изобретение велосипеда.

Ну вот у вас и была задача — сделать клиента для API, к которому готовых клиентов нет. Как вы будете на работе делать взаимодействие с API, которое в соседнем отделе разрабатывается? Попросите их специально для вашего проекта клиента написать? А вдруг вы сами в этом отделе будете работать, как вы клиента напишете?

ну вот я её и решил не тратя время на изучение тех вещей которые уже работают, в этом задании у меня был затык с фронт-эндом, плюс PHP за каким то чёртом заменяло пробелы на нижнее подчёркивание, вот это был ад, аж пришлось запариться на input:radio.
Я говорил не об этом, а о качестве кода и обучающего материала, которые появились в процессе ее решения.
Я совершенно не разделяю ваши методы разработки. Вот из-за таких, как вы, приходится обрабатывать невалидный YML через регулярки, а потом парсить.

схалявить и зафигачить JSON без json_encode, тупо вклеить

Мы же на хабре, тут такого не должно быть.
схалявить и зафигачить JSON без json_encode, тупо вклеить

если следовать принципу Keep It Simple Stupid — тупо текст из документации к API это проще чем генерация этого текста.
Хотя генерация конечно методологически надёжней, но документация API после публикации не поменяется.
принцип You ain't gonna need it говорит о выполнении необходимого минимума действий для достижения цели. Если модификация не предполагается, то «статичный» текст полностью удовлетворяет «условиям задачи»

О да, оправдывать не качественный код принципами KISS и YAGNI это круто

Код очень стилистически соответствует самому изложению. Эдакое размашистое разгильдяйство. Исключительно по моим ощущениям конечно.

главное код тестами покрыть :) а когда нет тестов, то живые пользователи тоже сгодятся, но в этом случае важно успеть накатить бэкап раньше чем пользователю прочухают в чём дело: )
UFO just landed and posted this here
Sign up to leave a comment.

Articles