nozzy

Это хороший вопрос, но однозначного ответа на него нет.

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

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

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

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

Это пример самой базовой и очень распространенной задачи - как сделать работу с SQL менее занудной и гарантированно безопасной. И начинать надо именно с таких задач, не замахиваясь на приложения целиком.

Если говорить о приложении целиком, то стоит попробовать написать что-то примере фреймворка Symfony - это как раз даст понимание того, как ООП применяется на уровне приложения.

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

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

Уже начиная от сюда - создана криптовалюта (и не одна, но имеет смысл только биткоин, почему - ниже), в которой с помощью блокчейна и надежного PoW консенсуса, создана 'амбарная книга' где записываются транзакции буквально 'кто кому сколько перевел монет' и все могут доверять этим записям при условии ограничений консенсуса (в случае с PoW это атака 50%+1 и возможность подобрать такое количество подтверждений от циркулирующих сумм, при котором этой атакой можно пренебречь)

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

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

Сначала создавались криптовалюты, как копирующие bitcoin так и реализация с нуля с необычным функционалом и концепцией, эксперименты с альтернативными консенсусами и прочим,.. которые показали что самого по себе консенсуса недостаточно для обеспечения надежного функционирования системы, нужны еще такие вещи как качественное первоначальное распределение ценности (монет блокчейна, если грубо) и наличие независимых разработчиков, более чем одна команда, грамотное управление и воля участников к поддержанию системы на плаву. Требование про разработчиков очень философское и есть куча примеров когда вне зависимости от консенсуса, главные разработчики, владельцы основного объема ценностей были связаны/созависимы, и были способны уничтожить полезный проект (например что произошло с bitshares, если что это показало на сколько PoS консенсус уязвим).

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

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

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

p.s. почему только bitcoin? потому что только в нем распределение богатств заметно равномерный (индекс джини), только его консенсус подкреплен огромными финансовыми вливаниями в оборудование для майнинга (очень дорогая атака) и огромное комьюнити независимых разработчиков (правда тут есть куча мест для слабости проекта, но по сравнению с другими - bitcoin выглядит как самый защищенный).
Остальные проекты создаются не с целью привнести что либо полезное миру, а с целью собрать денег, либо как сбор средств на разработку (ICO или комиссия в блокчейне), а когда консенсус основывается буквально на объеме денег (чистый PoS), то сам факт того что основные деньги проекта сосредоточены у кого то одного (создателя или олигополии инвесторов как это сделано в EOS, точнее dPoS проектах) полностью обнуляет любую защиту.

p.p.s. меня заинтересовал единственный альтернативный консенсус - proof of identity (сейчас это idena.io - примерно 2к-3к нод, 7к..14к 'майнеров' и количество растет ~10% в месяц , для молодого слабого проекта это чудо в криптоэкономике), основная беда большинства не PoW - возможность атаки количеством нод или деньгами, но тут одна идентити = один человек (ну ок, две - это норма), это гарантирует консенсус, а опасность сбора фермы рабов для атаки на проект усложняется низкой стоимостью монеты, т.е. как это не парадоксально, пока доходы майнеров тут будут низкими - консенсус будет надежным

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

хех, надо бы это оформить в виде статьи на хабр и отправлять народ туда

Правильно думаете, Google MAPS тут должен выступать в роли отображалки не более, а поиск на сервере. В противном случае вам придётся клиенту предварительно отдавать все точки, чтобы потом он мог у себя искать.

яндекс карты не относятся к вашей проблеме.
вопрос из области геометрии , как найти расстояние между двумя точками по координатам.
А точнее Вам требуется проверить, есть ли в вашей таблице базы данных объект(ы) в заданном
радиусе от указанных координат.
bit.ly/2E5EOo7

как раз то что для Вас нужно ympd

Либо EAV, либо поля типа JSON.

October CMS. Подходит для любых сайтов любой сложности. И главное - если хотите развиваться и изучать реально хороший, качественный код - это опять же, Октобер. Пример крутого приложения на крутом фреймворке (Ларавел). Его спокойно можно изучать и быть уверенным - не прогадаешь, это просто кладезь мудрости для прогера :)
Если брать поверхностно - есть два основных способа:
1. Плагин Static Pages, плюс Blog как пример реализации разных фишек. Это для "разносторонних" страниц, то есть например, есть страница "Главная" где вообще никакой схемы данных нету, а есть набор виджетов "всего понемногу", есть страница "О нас", где надо текстик wysiwyg и список "Наши партнеры" - объекты вида <баннер + заголовок>, "Контакты" - где опять же текстик, три поля для телефона, адреса и e-mail, и пару координат lat/lng для карты, и т.д. - все это дело в реляционную схему БД заталкивать - мучение. Тогда юзаем static pages, там кстати очень похоже на MODx Revo, если кто знаком: layouts - аналог templates, syntax fields - аналог TV, сами страницы - соответственно ресурсы, partials - аналог чанков, компоненты - аналог сниппетов (не путаем со snippets самих static pages, это немного другие, очень кстати полезные, штуки)
2. Плагин Builder для быстрого создания своих кастомных плагинов с БД, моделями, отношениями, и контроллерами бэкенда чтобы этим делом управлять. Это если есть например API, где 200 стран, 100К городов, а в них 2млн мест. Всё это надо скачать и распарсить в базу, и чтобы на выходе получилось 2080200 страниц с 5 шаблонами - один для страны, один для города и допустим ещё 3 под разные типы мест в городе (отель, кафе, достопримечательность). Легко! Пилишь 3 таблицы в БД, создаёшь модельки со связями и роутинг (url'ы прям в таблицах можно хранить, не забывая про индексы) и БЭМ! 2 ляма страниц не тормозят и удобно управляются из бэкенда, для бэкенда куча виджетов - список, форма, менеджер отношений (управлять связанными объектами, умеет и один-ко-многим и много-ко-многим и т.д.). Виджеты можно и свои создавать - как обычные виджеты, так и поля формы. Накидать CRUD набор страниц для управления сущностью в бэкенде - дело 5 минут. Пример с городами и местами довольно примитивный, т.к. тупо дерево из 3х уровней, но и более сложные вещи так же пилятся и не тормозят, хоть там к каждому из 2млн мест надо прицепить ещё по 10 сущностей с полиморфизмом и прочее, и выводить десяток виджетов на их страницах - тут уж ограничение - только умение проектировать БД.

Да там расписывать можно бесконечно :)

PS: В сети встречаются вопросы и issue на гитхабе, читая которые может сложиться впечатление, что ЦМС сырая. Но! Смотрим на дату этих вопросов - меньше 2х летней давности найти сложно. Сейчас там всё "вылизано", Ларавел подтянут до 5.5 LTS, в общем красота! Да, и самое главное - нет такой задачи, которая потребовала бы куда-то там лезть в ядро и что-то править. О таких вещах можно забыть напрочь. Да там даже мультисайтовость и мультиязычность контента - запилены в виде плагинов! Я в шоке был когда посмотрел, какие вещи там делаются просто как модуль расширения.

Я тоже хочу порекомендовать October CMS. Она на сегодня лучшая, построенная на компонентах Laravel. Но обманываться не стоит, разработка на October не то же самое. Но разрабатывая на October вы получите:

• отличный DX, нужно просто попробовать;
  
• CLI для автоматизации решения задач;
  
• самый популярный PHP-шаблонизатор Twig;
  
• действительно исчерпывающую документацию;
  
• возможность удобного совместеного использования с Laravel (кпример комплексного проекта - 2doc.by - October CMS, api.2doc.by - Lumen, medcrm.by - Laravel);
  
• аскетичность из коробки, следование философии Unix, что позволяет не быть изначально заточенной под конкретный тип проекта и не содержать в себе неиспользуемую проектом функциональность;
  
• отличный скафолдер для разработки кастомной функциональности под нужды проекта;
  
• непрерывно растущую базу плагинов с августа 2015 до мая 2017 росто составил 75% со 130 до 515;
  
• непрерывный рост интереса сообщества к платформе, выраженный в приросте звезд на гитхабе с 3000 в июне 2015 до 6950 в мае 2018;
  

Можно продолжать долго, если будет желание и необходимость. =) Из минусов можно отметить слабый рост количества готовых шаблонов, не такое большое количество дополнений в сравнении с динозаврами рынка CMS. Не минус, но важный момент, что на October вы будете именно программировать, это как порог входа для неквалифицированных разработчиков, так и дополнительные возможности для квалифицированных.

Что касается важной темы E-Commerce, есть несколько готовых дополнений разной степени качества и функциональных возможностей. Я порекомендую Shopaholic, т.к. имею непосредственное отношение к проекту и головой могу отвечать за его качество. Проект пока очень молодой, меньше полугода после релиза и тем не менее, отзывы наилучшие от сообщества (1, 2, 3, 4, 5, 6, 7 и т.д.). Вот неболшая статья в нашем блоге про Shopaholic.

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

Единственной в некоторой степени проблемой выбора не самой известной платформы может стать ее "продажа" клиентам. Но мы успешно с этим справлялись, работая 7 лет с MODX в мире, где правили Wordpress (весь мир) и Bitrix (СНГ). А последние 2,5 года также успешно справляемся с October в мире, где правят Wordpress и Bitrix и это еще теперь пытается делать MODX (СНГ).

Надеюсь, был полезен. =)

OctoberCMS
С одной стороны CMS
С другой laravel.
Тоесть вы не скатитесь к водпресу и подобным. И не будете терять квалификацию в фрэймворках, если вдруг надо будет сделать/прикрутить что-то не стандартное.

Vue.js

В App\Http\Middleware\VerifyCsrfToken пропиши:
protected $except = [
'api/*'
];

https://laravel.com/docs/5.4/csrf

$str = implode(',', $array) . '.';

CMS - система управления содержимым, как она может быть нацелена на флэт дизайн? Она нацелена на контент. «Блоговая система» это скорей всего вордпресс, но что вы имеет ввиду под этим понятием, я не знаю :)