Нужны уроки php, vue.js чтоб урок прошел, и сразу дз надо сделать. Дописать кусок кода чтоб закрепить материал.
желательно на русском
можно платные
Очень прошу не флудить. Если знаете, то напишите. Спасибо. Всем большого рейтинга
Всех снова приветствую! Занимаясь разработкой сервиса мониторинга цен меня просили также запостить информацию о технической части, как же это устроено, почему именно так. В первую очередь хочется поблагодарить пользователей пикабу за обратную связь и огромнейшую помощь в тестировании проекта, комментариям к его доработке и всем замечаниям которые я стараюсь устранять как можно скорее.
Конечно же сервис (я ранее о нём писал ТУТ) сильно изменился и действительно стал удобнее, я также отслеживаю на нём некоторые приложения — стало информативнее. Но всё же я стараюсь не забывать, что не бывает всё идеально! Понимаю, что еще много всего можно доработать, поэтому будем улучшать и делать информацию еще более полезной! Многие доработки на основе обратной связи я уже внёс, но разумеется будут еще! Итак, начнём наше слишкоммногобукаф =)
Получение информации и приложениях
Изначально при создании такого типа сайта нужно понимать откуда дергать информацию. По сути есть два способа, это прямой парс сайтов, либо использование XML / JSON. В данном случае парс просто "грабит" информацию с сайтов источников, XML / JSON даёт структурированные данные, которые мы обрабатываем на своей стороне.
— Парс: целая куча граблей в корректности информации, если источник изменил верстку — то сервис перестаёт работать и получать нужные данные, либо начинает "мусорить". Подобное уже случалось с Google Play Market, когда те обновили верстку и много информации попросту потерялось при получении данных о приложении.
— XML / JSON: эти данные имеют свою четкую структуру данных, которую мы принимаем на своей стороне и обрабатываем, то есть со временем у нас не пропадёт информация и поля с данными никуда не уедут.
В данном случае надёжным будет XML / JSON, т.к. точность данных не нарушается со временем в результате каких-то обновлений, исключением скорее может быть нерабочий сервис источника. В целом разработчики эти особенности знают.
Ок, откуда получать информацию о приложениях?
— Google Play Маркет (не даёт никаких API, тут нужен скрипт парсинга и никак иначе)
— AppStore (даёт RSS XML либо RSS / JSON)
— PS Store (даёт API JSON)
— Microsoft Store / Xbox Live Store (не даёт официального api, но есть сервис xboxapi.com, к сожалению платный)
— Steam (даёт API JSON)
// Appstore API
$url = file_get_contents('http://itunes.apple.com/lookup?id=XXXXXXX&country=ru%27);
$data = json_decode($url);
$data = $data->results[0];
// Выводим всю информацию о приложении, которую отдаёт нам Apple
print_r($data);
// Название$name = $data->trackName;
// Описание$description = $data->description;
// Категория$category = $data->primaryGenreName;
...
Данный отрывок кода — стандартное получение данных API из JSON AppStore, далее подставляем нужный ID, обрабатываем через PHP и погнали. Аналогично по данному типу работают все приложения, мы просто подставляем ID и запрашиваем свежую информацию о приложении. Сервис AppStore и, в нашем случае Google Play, не предоставляют информацию о скидках, они пишут только актуальную цену и всё, поэтому её мы пишем в базу, запоминаем и сравниваем с периодичным обновлением по крону. Способ не самый изящный, но другого в принципе нет. Разве что можно писать не в базу, а в файлы, но где хранить информацию это скорее вопрос оптимизации скрипта и данных. В других сервисах аналогично, за исключением Play Market-a.
Остальные сервисы по аналогии, ставим на Cron и обновляем каждые 1-2 часа для поддержания актуальности данных. И вот мы потратили много времени и подготовили все скрипты по подгрузке и обновлению данных. Теперь мы вынуждены столкнуться с некоторыми нюансиками этого проекта, о чём и пойдёт речь далее.
Без нюансов? Нет, не слышал!
Для расширения функционала сервиса и улучшения его качества появляются те самые нюансы, которые приносят расходы:
— домен и хостинг (это обязательная часть сайта — без них никуда. Т.к. проект работает с большим объёмом информации, то обычный дешевый хостинг не пойдёт, а это уже от 300 руб./мес., но я не сторонник хостингов и поэтому проект ушёл на вдс, т.к. хостеры часто любят ограничивать нас выделенной памятью, временем выполнения скрипта, отключать директиву allow_url_open и еще целая куча косяков и приколов в зависимости от хостера)
— xbox api — является платным (аналоги я искал долго и упорно — ничего нет). Бесплатный тариф имеет ограничения (60 запросов в час), которые быстро будут исчерпаны при заполнении раздела приложениями.
— SMS уведомления для тех, кто не читает почту и воспринимает её как сборник спама. Чтобы это полноценно работало и точно приходили оповещения (а не через раз), пришлось воспользоваться сервисом смс. ру и через него слать сообщения, которые оплачиваются в среднем от 3 до 7 руб. за шт в зависимости от условий и содержания сообщения.
То есть получается, что я стараюсь сделать проект, который будет полезен и поможет получить халяву, но при этом плюсуются обязательные расходы. Я даже не считаю личную занятость и затрачиваемое время, т.к. мне самому интересно и это моё хобби, хочется сделать полезный продукт несмотря ни на что, плюс я тоже им пользуюсь. Но вот расходы получается неотъемлемая часть проекта и в любом случае мне нужно их минимизировать, в результате чего мне пришлось ввести платный аккаунт с минимальной ценой (промо коды на полный акк я давал в самом первом посте) для компенсации расходов по самым минимальным подсчетам и вынужден немного ограничить рамки пользователей.
Рассмотрим эти расходы на примере грубых подсчетов
— Например, что сейчас на сайте 500+ пользователей, каждый из них может быть подписан на 30 приложений. Выходит 15000 уведомлений в день на готовности рассылки, из которых может быть 5% оповещений, а это 750 шт минимум. Даже если 10% пользователей будут пользоваться смс уведомлениями, это 75 смс уведомлений по средней цене 5 руб за штуку, так мы получаем 375 руб. в день расходов только на смс, а это 11+ тыс. рублей в месяц при самым грубым подсчетам!
Вот так вот, сделал доброе дело называется!
Бюджет Xbox Api более щедящий, просматривая тарифы я думаю вполне будет достаточно 400-1000 запросов в час за 2 фунта (189 руб) или 5 фунтов (473 руб) в месяц, чтобы это было с запасом, но это зависит напрямую от количества приложений на сайте, которое всегда пополняется.
Чтобы сервис работал и давал максимум функционала и минимум граблей — это не много. Не спорю можно сделать обычный парс и снизить эти расходы, но если вся конструкция развалится, то будет не очень хорошо.
По итогу выходит, что минимальные расходы ежемесячно на такой тип проекта могут быть примерно 12 т.р. в месяц по самым грубым подсчетам (144 000 руб в год). В общем как я уже писал, это всё крайне грубые подсчёты, прошу не ругать меня. Вообще логично, что такой сервис и вовсе должен быть фулл фри (ну или фулл картошека по деревенски).
Эти расходы не нужны, на основе отзывов пользователей вероятно потребуется исключать функционал с СМС, пусть все пользуются!
НЕСИТИ КОФИ! ГДЕ КОФИ!? Нужно больше информации!
И так, когда наш мозг уже окончательно перестал соображать после написания всех скриптов, учёта нюансов — у нас есть еще задачи по улучшению и мы начинаем прикручивать магазины для сравнения цен.
Аналогичная ситуация с API / XML, если есть структурированные данные, то мы можем полноценно с ними работать. Но не все магазины их предоставляют, чаще это магазины с наличием партнерок. Подключаем доступные (Steam pay, steam buy, Бука). Теперь у нас есть сравнение цен.
Далее полным ходом идёт подбор магазинов, а это процесс сам по себе не быстрый. Кстати, магазины с партнёрками дают откаты проекту с продаж (но не все), то есть не наценку за товар, а именно откат, при котором магазин зарабатывает чуть меньше. В целом я думаю вполне корректно рассмотреть это как альтернативу компенсации финансов на обслуживание проекта, которую я думаю многие поддержат, ведь проект выходит в каком-то смысле на "самокоменсацию" за счёт подключаемых магазинов, а не пользователей. НО к сожалению их не много, поэтому на данный момент это не работает должным образом, остаётся лишь тестировать. Теперь, когда всё работает, подгружается, сравнение цен дополнило картину — я должен отметить, это действительно очень удобно. Нужно подключать вообще все на свете магазины больше магазинов!
Подключаю я значит сервис Plati, а там продавцы не имеют никакого регламента по заполнению названий и описания продуктов, в итоге мы имеем полный бардак в поиске и подборе названий товаров для сравнения. Я постарался обработать информацию как мог находя точные совпадения названий к товарам с учётом их обработки и удаления спецсимволов.
Кустарный способ обработки, т.к. символы дополнял и проводил определенные тесты, но уже переписал в массив и скорректировал код. Теперь мы перестали учитывать с обеих сторон всякие ТМ, Р и прочий мусор, который где-то есть, а где-то его нет. Информация о ценах стала подгружаться лучше, вроде работает. Теперь рассматриваю новые магазины, в обратную связь писали про Zaka-Zaka, но API они не предоставляют, к сожалению. Во многих местах там зацепиться не за что, а переходить на обычный парс HTML страниц не надёжно, хотя не всё же не исключаю такой ход для обеспечения функционала, написал определенную защиту и автоматически отключать показы в случае, если информация пошла некорректно.
Подведём итоги
Получается для создания подобного проекта (который совмещает в себе кучу разных магазинов и платформ, а также умеющий автоматом информировать) нужно не только выделить огромное количество своего времени помимо рабочих задач, учитывать интересы пользователя (это конечно в первую очередь, иначе все старания будут напрасны). Сколько себя знаю, занимаясь ковырянием в носу разработкой с примерно 2007 года (тогда я только начинал вникать во всё это и потихоньку изучать HTML) — я всегда мечтал построить что-то дельное, полезное и для людей! Теперь я понимаю, что такой проект я сделал и на основе отзывов можно сказать, что он действительно полезен, а поэтому — моя цель сделать еще лучше, еще интереснее и еще полезнее! Поэтому буду надеяться на Вашу помощь и поддержку, ведь поддержка в данном случае это и есть главная мотивация.
ps. Отдельные технические моменты я не стал писать, было и есть множество сложностей, все их тяжело описать одним разом и везде уделить внимание, плюс всё же чисто технический пост с кодом будет актуален скорее для других площадок.
еще. Скажу так, терпения тоже нужно очень много, иногда ошибки появляются даже чисто случайно и приходится в срочном режиме всё исправлять, а в некоторых случаях на это может уйти много времени.
В общем, стараюсь для Вас как могу!
Credits:
Не сплю, не ем, работаю над проектом и заряжаюсь от сети:
А это после очередного большого обновления:
Добрый день Пикабу, это мой первый пост в этой теме и на написание его меня сподвигло потерянное время на устранение ошибки описанной в названии. Мне просто хочется, чтоб человек столкнувшийся с аналогичным случаем мог бы найти мой пост и решить свою проблему.
Собственно сам код (упрощенный до предела).
<Условие>//верное через отладчик видно, что выполняется
unset($a[i][j]); // опять таки массив и указанный элемент в этом моменте существует.
//Здесь $a[i][j] все ещё продолжает существовать, а ведь не должен.
Не знаю как в других программах, но в режиме отладки phpstorm $a отображался как массив. Визуально все выглядело правильно, но не работало. Как оказалось проблема с преобразованием из json. Значения в массив попадали вот таким образом.
$a=json_decode($str);
И вроде бы в $str содержался преобразованный массив и даже несколько раз все отработало правильно, а потом алгоритм стал вести себя иначе.
Как это лечится?
$a=json_decode($str,1);
То есть указываем, что наш json нужно преобразовывать в ассоциативный массив. Теперь я во всех возможных случаях использую эту функцию именно в таком виде.
Также в этой же ситуации возможна вот такая картинка:
$a[1]=>1
$a[1]=>2
То есть индекс одинаков, но значения разные. Логично предположить, что json преобразовался не в массив, а в std класс. Может кто-то из жителей сообщества объяснит ситуацию конкретнее. Так же если нужно преобразование из std класса в массив, то тоже советую делать это через
json_encode и json_decode($val,1) хотя за потребляемые ресурсы в процессе подобных преобразований не отвечаю, в моем случае операция выполнялась редко и с небольшим объемом.
А теперь немного о проблемах, которые увидела на форумах.
foreach($ar as $val)
unset($val); //с массивом $ar ничего не произойдет, так как удаляются только копии элементов.
правильный вариант
foreach($ar as $key=> $val)
unset($ar[$key]); //после цикла получим пустой массив
Или же еще $ar у нас двухмерный массив.
foreach($ar[1] as $key=> $val)
unset($ar[1][$key]);
Значение $ar[1] в массиве будет и оно будет содержать пустой массив, если нам нужно чтоб $ar[1] вообще не было, если он пуст пишем после цикла условие наподобие:
if (empty($ar[1])) unset($ar[1]);
Спасибо за внимание и обратите внимание на комментарии, автор сего поста может ошибаться и возможно, это будет видно в комментариях.
Мысли о конкретных моментах в разработке и попытка организовать более конструктивное обсуждение кода.
Привет всем! Ребята, которые шарят в php, нужна помощь, как можно сделать систему сообщений, чтобы сервер выжерживал большого количества людей?
Моя супруга по образованию учитель математики, до ухода в декрет работала дизайнером-верстальщиком в газете.
После двух декретных подряд решила заняться разработкой сайтов.
Полтора года назад для этого мы приобрели для неё курсы Куртеева по Джумла и она эти курсы прошла. Во время и после этого она сделала на Джумла несколько лендингов на заказ и блог для меня.
Столкнулась с недостатком знаний - некоторые вещи не удается сделать без глубокого понимания кода и логики работы движка.
В частности две проблемы, которые не удалось решить:
1. Защита сайта. Через полгода функционирования сайтов(был запущен мой блог и несколько лендингов) они подверглись вирусному заражению и были забанены поисковиками. Жена восстановила каждый сайт из бэкапов и теперь практически каждый день проверяет их на вирусы. К сожалению, четкой причины заражения сайтов ей выяснить не удалось и как предотвратить это в будущем - непонятно.
2. Сайты проиндексированы, по ключевым запросам страницы выходят в выдаче, но в статистике яндекса нет переходов из поисковых систем и посещаемость на них крайне низкая(возможно, это связано с прошлым заражением, хотя прошло более полугода уже).
Искали с ней пути решения, но не нашли ни вменяемого русскоязычного комьюнити(по английскому она - элементари пока), ни в саппорте joomla.center не помогли и знакомых квалифицированных вебмастеров тоже нет.
Тогда, чтоб она могла разбираться сама с этими и подобными задачами, мы преобрели ей доступ к курсам на fructcode. Жена прошла больше половины до курса по php включительно, но впечатления не очень - очень много моментов, в которых нет объяснения, которое было бы необходимо, а преподаватель просто пишет код.
Жена хочет развиваться в данном направлении и осваивать веб, но непонятно в каком направлении двигаться и как это сделать эффективнее.
Просто читать книги ей не заходит(Тут я её понимаю - мне тоже не заходили, когда я осваивал программирование на 1С).
Вот мои наблюдения о входе в профессию вебпрограммиста:
1. Непонятно, какие технологии осваивать.
Когда я осваивал программирование на 1С, то тут примерно было всё понятно: сначала были желто-красные книжки чтоб понять как работать в пользовательском режиме в 1С, код типовых конфигураций на 1С77 и листинг с примерами. Потом были видео от "Курсы-по-1С", Радченко и курсы/книги/метод тыка для освоения пользовательского режима. Какие технологии надо знать - предельно понятно + дружелюбное комьюнити в виде Инфостарта и Мисты.
Тут же куча CMS претендующих на мировое господство, в каждой куча компонентов, модулей и плагинов, реализующих часто один и тот же функционал, но по-своему. Много мнений, что не надо пользоваться готовыми, но надо писать свою CMS. Всякие там React, там Angular, Vue другие фреймворки и хрен поймешь, за какую хвататься.
2. Отсутствие плана обучения.
Этот пункт напрямую вытекает из предыдущего, ибо не зная куда идти никуда и не придешь.
3. Отрыв основ от практики. Поясню, что имею ввиду на примере 1С: ты прочитал учебник Радченко и даже написал пару конфигураций, вышел на работу и тут тебе дают небольшую задачку, в которой надо подправить что-то незначительное в типовой конфигурации, основанной на библиотеке стандартных подсистем. Т. е. прочитав книгу по php, к примеру, написать/подкорректировать компонент для той же Джумла.
В связи с текущей семейной ситуацией предпочтительнее было бы, если б супруга работала удаленно. Это либо фриланс - изготовление сайтов на заказ самостоятельно, либо удаленная работа не на полный день.
На данный момент мы рассматриваем покупку для неё курсов GeekBrains или Skilbox(ко вторым больше склоняемся). Мне кажется, что это должно дать результат. Но они стоят как самолет, наверное сравнимо со стоимостью высшего образования или даже больше. Насколько оправданы такие затраты, вот в чем вопрос.
Собственно, нужен совет от опытных вебпрограммистов и, возможно, какая-то методическая помощь в построении плана обучения. Подскажите, как эффективнее войти в профессию, какие технологии и в каком порядке надо осваивать? Может быть подскажете какими ресурсами лучше пользоваться новичку, осваивающему данные технологии? Если имеете опыт прохождения каких-то комплексных курсов для входа в профессию и этот опыт положительный, то что-то посоветуете?
Заранее спасибо!
