Привет! Маркет не то, чтобы начал заигрывать с Беру.ру, просто Яндекс и Сбер некогда создали Беру на двоих, потом поругались, беру.ру осталось Яндексу и они его, конечно, переименовали в Я.Маркет, что немедленно родило путаницу с одноименным каталогом товаров.
В общем, мне как постоянному и очень лояльному заказчику беру.ру/маркета уже тоже расхотелось у них что-то покупать.
А у Wildberries ассортимент пока не настолько универсальный, много, что обычно заказываем, там просто нет. Но да, по логистике и поддержке они — лучшие на сегодняшний день.
Автор, у меня к вам два вопроса:
1. Почему бы не использовать статическую генерацию какого-нибудь модного фронтенд-фреймворка? Например, такое есть у nuxt.js из экосистемы vue. Уверен, есть и у Реакта, и у Ангуляра, просто не изучал этот вопрос. Так вот, генератор статики nuxt умеет при формировании страниц обходить с помощью написанной вами функции динамические маршруты, дергать, например, серверный api, и генерировать из этого статические файлы. Серверный api, при этом, может быть быстро написан на чем-то типа symfony+api platform, laravel тоже умеет в api. Хочется больше самописного — используйте slim, отличная штука. Но зачем генерировать html статику силами php?
2. Я так и не понял, с какой такой целью вы всё запихнули в один php файл? Как это потом поддерживать? Или разработка идет нормальным образом, а при сборке все склеивается в один файл? Но все равно, непонятно, зачем. Есть же phar, например. Есть докер. Да просто установить cms через composer create-project разве сложно?
В общем, идея ясна и вполне оправдана (имею проект, у которого основная часть страниц сгенерированы в статику и только админка/личный кабинет представляют из себя spa с api на php). Но вот реализация, на мой взгляд, странная
Специалист по кибербезопасности хвалит Wordpress?! Это забавно:))
А если по сути — даже не знаю, какая должна быть маржа от продажи плагинов к вордпрессу, чтобы добровольно согласиться их разрабатывать и вообще работать с кодовой базой и экосистемой вордпресса. Для того, чтобы компенсировать моральные издержки и состояние постоянной ненависти (как результат чтения говнолапшекода) нужны просто огромные доходы!
Ну это тоже можно же было сделать силами реакта, а из php с помощью какого-нить Guzzle дергать нужный роут реакта, получать полный html в ответ и делать с ним, что угодно.
Кстати, а зачем вообще конструктору сайтов сохранять html в бд? Мне кажется, правильнее было бы хранить именно json. Если завтра юзер захочет заголовки поменять местами — он просто их поменяет. Если нужен на выходе статический сайт — ну у реакта наверняка есть в next.js такая фича, как генератор статики. Никакого смысла не вижу дублировать этот функционал.
Тут, если пойти дальше, то можно вообще дать выбирать фронтенд клиенту, подгружать, скажем, свои компоненты в конструктор. Выбрать, например, Вью вместо Реакта. А базу сохранять дерево из абстракций. Если сохранять html, ничего такого не выйдет уже.
При чем тут деньги? Вот это вот все надо переписывать с нуля. Это гораздо больше денег, чем сразу писать нормально. Вы просто плохой программист (или не вы, а тот, кто это писал). И учиться, судя по всему, не желаете. Перенимать опыт и лучшие практики других разработчиков — тоже. Страшно даже подумать, что у вас там с безопасностью. Использовать это даже для небольшого бизнеса — крайне опасно.
Так что нет, через год-два я тоже не зайду. Ничего не поменяется принципиально, уверен.
А почему СРАЗУ не писать нормально? С тестами, соблюдая стандарты и шаблоны проектирования?
Сначала заинтересовался идеей, потом немного напрягло описание в статье, а потом я заглянул в код, ужаснулся и закрыл. Нет уж, ешьте сами с волосами!
О, про вопросы из зума — это отличные новости, спасибо! Потому что я так и не смог к этой глючной штуковине полноценно подключиться.
По поводу шарить можно — отлично, еще раз спасибо! Непонятно только, зачем такое в письме написали...
ekaterinaryabukha, здравствуйте!
Имею PHPStorm 2020.1.1. Но автокомплишена vuex, разбитого на модули, не имею. Пока в мою IDE не завезли или надо что-то где-то включить?
Мне вот не нравится macOS по ряду причин. Но в отличном десктопном интерфейсе ей не откажешь. А она тоже в некотором роде FreeBSD. Так что можно и очень хорошо затюнить:))
Привет! Маркет не то, чтобы начал заигрывать с Беру.ру, просто Яндекс и Сбер некогда создали Беру на двоих, потом поругались, беру.ру осталось Яндексу и они его, конечно, переименовали в Я.Маркет, что немедленно родило путаницу с одноименным каталогом товаров.
В общем, мне как постоянному и очень лояльному заказчику беру.ру/маркета уже тоже расхотелось у них что-то покупать.
А у Wildberries ассортимент пока не настолько универсальный, много, что обычно заказываем, там просто нет. Но да, по логистике и поддержке они — лучшие на сегодняшний день.
Гражданин, вы истеричка. Вам нужно обратиться к специалисту, он сможет прописать нужные успокоительные.
А, ну то есть, если самый быстрый по бенчмаркам, то уже и не важно, что он без тестов, и з сомнительным качеством кода?! Окай, буду знать:))
Роман, а вы смотрели в код вот этого вот?
Тестов нет, мин.версия PHP 5.3, посмотрел по диагонали код — глаза не вытекли, конечно, но слезы проступили…
что это и зачем это в дайджесте?!
Я правильно понимаю, что обычно, у более других языков, "полноценная экосистема" возникает сама собой, ее никто не пишет?
1. Почему бы не использовать статическую генерацию какого-нибудь модного фронтенд-фреймворка? Например, такое есть у nuxt.js из экосистемы vue. Уверен, есть и у Реакта, и у Ангуляра, просто не изучал этот вопрос. Так вот, генератор статики nuxt умеет при формировании страниц обходить с помощью написанной вами функции динамические маршруты, дергать, например, серверный api, и генерировать из этого статические файлы. Серверный api, при этом, может быть быстро написан на чем-то типа symfony+api platform, laravel тоже умеет в api. Хочется больше самописного — используйте slim, отличная штука. Но зачем генерировать html статику силами php?
2. Я так и не понял, с какой такой целью вы всё запихнули в один php файл? Как это потом поддерживать? Или разработка идет нормальным образом, а при сборке все склеивается в один файл? Но все равно, непонятно, зачем. Есть же phar, например. Есть докер. Да просто установить cms через composer create-project разве сложно?
В общем, идея ясна и вполне оправдана (имею проект, у которого основная часть страниц сгенерированы в статику и только админка/личный кабинет представляют из себя spa с api на php). Но вот реализация, на мой взгляд, странная
Специалист по кибербезопасности хвалит Wordpress?! Это забавно:))
А если по сути — даже не знаю, какая должна быть маржа от продажи плагинов к вордпрессу, чтобы добровольно согласиться их разрабатывать и вообще работать с кодовой базой и экосистемой вордпресса. Для того, чтобы компенсировать моральные издержки и состояние постоянной ненависти (как результат чтения говнолапшекода) нужны просто огромные доходы!
Роман, а куда написать-то? Только в твиттер или есть еще контакты? Два раза прослушал видео с сайта слоников, но так ничего и не понял:)))
Ну это тоже можно же было сделать силами реакта, а из php с помощью какого-нить Guzzle дергать нужный роут реакта, получать полный html в ответ и делать с ним, что угодно.
Кстати, а зачем вообще конструктору сайтов сохранять html в бд? Мне кажется, правильнее было бы хранить именно json. Если завтра юзер захочет заголовки поменять местами — он просто их поменяет. Если нужен на выходе статический сайт — ну у реакта наверняка есть в next.js такая фича, как генератор статики. Никакого смысла не вижу дублировать этот функционал.
Тут, если пойти дальше, то можно вообще дать выбирать фронтенд клиенту, подгружать, скажем, свои компоненты в конструктор. Выбрать, например, Вью вместо Реакта. А базу сохранять дерево из абстракций. Если сохранять html, ничего такого не выйдет уже.
При чем тут деньги? Вот это вот все надо переписывать с нуля. Это гораздо больше денег, чем сразу писать нормально. Вы просто плохой программист (или не вы, а тот, кто это писал). И учиться, судя по всему, не желаете. Перенимать опыт и лучшие практики других разработчиков — тоже. Страшно даже подумать, что у вас там с безопасностью. Использовать это даже для небольшого бизнеса — крайне опасно.
Так что нет, через год-два я тоже не зайду. Ничего не поменяется принципиально, уверен.
А почему СРАЗУ не писать нормально? С тестами, соблюдая стандарты и шаблоны проектирования?
Сначала заинтересовался идеей, потом немного напрягло описание в статье, а потом я заглянул в код, ужаснулся и закрыл. Нет уж, ешьте сами с волосами!
О, про вопросы из зума — это отличные новости, спасибо! Потому что я так и не смог к этой глючной штуковине полноценно подключиться.
По поводу шарить можно — отлично, еще раз спасибо! Непонятно только, зачем такое в письме написали...
Не знаю, в чем конкретно смысл, но после именно онлайн-конференции я получил вот такое письмо:
https://photos.app.goo.gl/M1HCwP2uskVjqVam6
Роман, а так точно можно было? Мне в письме было написано, чтобы я не делился ссылками на эти записи.
За wp в ядре PHP отдельно спасибо!:))
Спасибо большое за быструю реакцию! Вы — лучшие:))
В поддержку обязательно напишу
ekaterinaryabukha, здравствуйте!
Имею PHPStorm 2020.1.1. Но автокомплишена vuex, разбитого на модули, не имею. Пока в мою IDE не завезли или надо что-то где-то включить?
Что-то я не понял сложности добавления контейнера от Симфони в Ламинас. Подумал даже, что туплю и перепроверил. У Симфони PSR-11 контейнер — вот https://github.com/symfony/dependency-injection/blob/24918d956cec89aebdf9dd69fc569a980469be3c/ContainerInterface.php#L25
Laminas поддерживает любой PSR-11 контейнер. Профит
Мне вот не нравится macOS по ряду причин. Но в отличном десктопном интерфейсе ей не откажешь. А она тоже в некотором роде FreeBSD. Так что можно и очень хорошо затюнить:))
Боже мой, это хабр?! Единственный здравый комментарий получил минус...
Интересно! Пожалуйста, продолжайте. В технических статьях в том числе:))