В принципе, логика есть. Яндекс типа российская компания. Там у неё офис, а здесь кухня. Нормальный шаг сделать её либо российской, либо создать конкурента и лишить доли рынка. Ребята, что значит, отжать? Если бы была поставлена именно эта цель, её бы уже достигли. Тем более, что вариантов масса. Один только Дзен даёт поводов начать каяку. И Яндексу это звоночек. Так у нас в Краснодаре в зерновой сфере сделали. Вызвали директоров и сообщили, либо платят я налоги и деятельность прозрачная, либо… Несколько человек не послушали. Их компаний, как бы уже и нет, а кто-то сидит. Лично я за то, чтобы Яндекс стал именно российской компанией. Но сначала надо создать условия, а потом требовать
Я поясню.
1. Здесь полностью согласен
2. Валидация здесь совсем не нужна (т.к. это черновик реального проекта, там это чуть иначе реализовано и форм для ввода нет).
3. useroks — здесь хранятся acess_token пользователя. Есть и uservks. Таблицы я разделил. Можно и в одной, но не стал. Мало ли какие ещё настройки по API придется вписывать.
4. ksort нужен. Это я параметры сейчас составил в алфавитном порядке. Но если их не отсортировать, то мы получим всё ту же ошибку 104.
5. foreach в данном случае быстро и просто решает задачу — создать строку из параметров ключ=значение (см. документацию APIOK)
6. sekret_key. Это наименование из мануала в ВК. Здесь для наглядности. Вообще я за очень короткий код и минимум переменных. Но на этапе поиска решения иной раз приходится идти на жертвы.
7. Я аргументы убрал почти со всех функций. У меня много асинхронных запросов на api маршруты. И для проекта есть своя система управления правами. Короче в моем случае все аргументы передаются через $request, а middlewear определяет принадлежность токена пользователю, какие права у группы пользователя на конкретный маршрут (1 разрешено всё, 2 операции только со своей информацией, 3 запрещено, опять же если в БД как-то заявлены права на маршрут, но для конкретной группы пользователей ничего не написано, то автоматом права 3 — запрещено). В моем случае — это одно из решений. Бюджет заказа не скажу, что большой, поэтому делаю то, что быстро, что работает, попутно оставляю комментарии.
Но Вы дали мне вполне ценную информацию и замечания. И я несомненно учусть, в т.ч. благодаря Вам.
Это Laravel. Я делаю заказ. Curl потому что он точно у меня установлен, я умею с ним работать и сдавать нужно вчера, поэтому даже в голову не пришло что-то другое взять. Честно, с Guzzle не работал. Но! Я делаю отдельный свой проект, изучу и, возможно, буду использовать.
По коду. Принято. Но это иллюстрация, к тому же мой черновик. Но за замечание отдельное спасибо, грешу.
Давно не было меня на Habr. Лид — заявка. Взять проект на управление — выстроить систему генерации заявок и их обработку. Спасибо за замечание. Это помогает писать более понятные статьи.
А что такое «ТС»? ))) Извините (я не всегда правильно расшифровываю аббревиатуры). Я прочитал Ваш комментарий ниже. Изучаю всё. Вообще, за последнюю неделю я очень продвинулся в изучении Laravel, Comoser, бегло PSR2. Мне ещё, конечно, учить и учить. Пилю для этого проектик (он и для работы нужен, и для изучения).
Я так и сделал. А адекватный клиент — я сам ))) И сроки поджимают не просто так ))) Но спасибо сообществу. Это подстегнуло к очередному витку развития.
Я и не пытаюсь )) Сейчас речь идет о создании работающего прототипа. Там относительно все просто. Во всяком случае на моем кривом фреймворке это делается за вечер.
Не смотря на отрицательный отклик на статью, я всё же получил бесценный пинок под зад и очень продвинулся. Сейчас, не спеша, спешу. Изучаю плотно и вдумчиво матчасть
Огромное спасибо. Конструктивный комментарий. И самое интересное то, что я как раз начал почти в таком порядке. Сейчас изучаю Laravel, параллельно (пока без фанатизма) просматриваю, что под капотом. Я создал два проекта — один черновик для Laravel, другой чистовик. Там бекенд (на Ларавел) и во фронтенд воткнул vue.js. Кстати, все оказалось не так сложно. И мой рецепт для себя в том, что я создам работающий прототип (аккуратно) с простыми функциями (на уровне 1-го класса), получу первый отклик и уже потом передам программисту, будучи уверенным, что смогу оплатить его труд.
Я прекрасно знаю Modx, когда-то изучил Evo, потом Revo. Нет, этот продукт не подойдет. Вообще, я определился и с фреймворком и с архитектурой, и уже накидываю проект в процессе изучения. Я разделил Backend и Frontend по разным адресам. Определился с маршрутами, списком контроллеров. Сейчас отрабатываю в Laravel простые упражнения и вникаю во фреймворк. На стороне Frontend у меня Vue.js, но до фронтенда руки не дошли пока, т.к. мне нужно создать нормальный бекенд, дождаться ответа по документации API от одного из партнеров и т.п.
1) Я знаком со многими CMS (WP, Joomla, Bitrix, OpenCart). Контента не предполагается в привычном виде, а тот, что будет формируется несколько иным способом, чем предлагается в классическом виде.
2) Да, подходит именно PHP по нескольким причинам: скорость разработки; часть функционала уже даже готова (на PHP). Остальные варианты (Python) тоже здорово, но это будет дольше (потому что мне нужно собрать денег на спеца и оторвать его от текущей своей работы), дороже и не факт, что проект выстрелит (простая статистика — часть проектов не работает).
О тостере. Знаете чем мне нравится сообщество программистов? В отличие от многих других профессий здесь люди делятся своими знаниями куда охотнее. Если я напишу на тостере, то там мне дадут технические советы. Эта же статья стоила мне нескольких баллов рейтинга, но вместе с вашими комментариями, она окажется куда полезнее поста на том же тостере. И, возможно, среди читателей кто-то в таком же положении. И это будет ему полезно тоже. Хотя, конечно, как и любой другой человек на планете Земля, я думал, в первую очередь, о себе.
Я не знаю, как Вас зовут. Хотел бы по имени обратиться. Я не настолько неопытен, как кажется. Скажу так, программированию мне учиться и учиться, но в свое время, работая в веб-студии мы переделали много проектов на UMI, Joomla, OpenCart (давно это было). Кстати, кодить мне нравится и я достиг бы много, если бы был постоянно в профессии. Но моя ниша в этой сфере — быстро накидать прототип, протестировать нишу и спрос и после этого приглашать спеца. Что касается моего корявого фреймворка, то на нем я накидал проектик, который себя более чем отбил. Но ряд управленческих ошибок спровоцировали кассовый разрыв и вынужденный отказ от одного из направлений. Другой моей ошибкой было то, что достигнув определенного уровня, я пригласил менеджера по продажам, а не программиста. До эры с фреймворками я начал активно изучать именно CMS. Достаточно нестандартное. И ни один из предложенных продуктов не подходит. Магазинного там будет часть, но это совсем нестандартная для классических Интернет-магазинов структура. Но опять же, это не магазин, хотя этот функционал будет присутствовать, но с очень большими особенностями и с оглядкой на текущие бизнес-процессы. Сейчас у меня ровно такая же задача — накидать рабочий прототип (без фанатизма), получить первые отклики, понять, что к чему, увеличить трафик и подтянуть программиста в команду (уже есть, но ему за этот проект надо платить, а я на мели). И было правильное замечание, ему нужно передать проект, с которым он сможет работать. Я уже установил Laravel, начал накидывать структуру (на бумаге), изучаю документацию, делаю первые уроки. Думаю, что все получится.
В принципе, логика есть. Яндекс типа российская компания. Там у неё офис, а здесь кухня. Нормальный шаг сделать её либо российской, либо создать конкурента и лишить доли рынка. Ребята, что значит, отжать? Если бы была поставлена именно эта цель, её бы уже достигли. Тем более, что вариантов масса. Один только Дзен даёт поводов начать каяку. И Яндексу это звоночек. Так у нас в Краснодаре в зерновой сфере сделали. Вызвали директоров и сообщили, либо платят я налоги и деятельность прозрачная, либо… Несколько человек не послушали. Их компаний, как бы уже и нет, а кто-то сидит. Лично я за то, чтобы Яндекс стал именно российской компанией. Но сначала надо создать условия, а потом требовать
1. Здесь полностью согласен
2. Валидация здесь совсем не нужна (т.к. это черновик реального проекта, там это чуть иначе реализовано и форм для ввода нет).
3. useroks — здесь хранятся acess_token пользователя. Есть и uservks. Таблицы я разделил. Можно и в одной, но не стал. Мало ли какие ещё настройки по API придется вписывать.
4. ksort нужен. Это я параметры сейчас составил в алфавитном порядке. Но если их не отсортировать, то мы получим всё ту же ошибку 104.
5. foreach в данном случае быстро и просто решает задачу — создать строку из параметров ключ=значение (см. документацию APIOK)
6. sekret_key. Это наименование из мануала в ВК. Здесь для наглядности. Вообще я за очень короткий код и минимум переменных. Но на этапе поиска решения иной раз приходится идти на жертвы.
7. Я аргументы убрал почти со всех функций. У меня много асинхронных запросов на api маршруты. И для проекта есть своя система управления правами. Короче в моем случае все аргументы передаются через $request, а middlewear определяет принадлежность токена пользователю, какие права у группы пользователя на конкретный маршрут (1 разрешено всё, 2 операции только со своей информацией, 3 запрещено, опять же если в БД как-то заявлены права на маршрут, но для конкретной группы пользователей ничего не написано, то автоматом права 3 — запрещено). В моем случае — это одно из решений. Бюджет заказа не скажу, что большой, поэтому делаю то, что быстро, что работает, попутно оставляю комментарии.
Но Вы дали мне вполне ценную информацию и замечания. И я несомненно учусть, в т.ч. благодаря Вам.
По коду. Принято. Но это иллюстрация, к тому же мой черновик. Но за замечание отдельное спасибо, грешу.
2) Да, подходит именно PHP по нескольким причинам: скорость разработки; часть функционала уже даже готова (на PHP). Остальные варианты (Python) тоже здорово, но это будет дольше (потому что мне нужно собрать денег на спеца и оторвать его от текущей своей работы), дороже и не факт, что проект выстрелит (простая статистика — часть проектов не работает).