Привет, а вы считаете это недостатком? Я когда-то давно (во времена php 5.4) делал редактирование схемы «на лету» в проде, но если бы делал сейчас — наверное сделал бы именно через кодогенерацию + коммит.
Спасибо организаторам и докладчикам за клевый ивент! Делюсь своим бесценным (и запоздалым) мнением об увиденном.
1) Выступление Александра Башкирцева было интересным, но не очень понятным =) Уловить мысль получилось, только почитав и пощелкав демо-код с включенным vue-плагином. Демонстрация и разбор кода, видимо, не влезли в регламент. Кто еще не ознакомился — ознакомьтесь обязательно: github.com/abashkirtsev/forms-example
Меня слегка сбило с толку название доклада, я скорее надеялся послушать про организацию верстки. Часто, особенно в CRUD-приложениях, верстать формы руками не хочется, потому что их много и они плюс-минус похожие. Можно взять генератор типа такого: github.com/vue-generators/vue-form-generator — и радоваться, пока не понадобится прикрутить что-то кастомное куда-то вглубь пирога «форма — строчки — поля». А когда понадобится — чесать репу, как бы так заинжектить нужный кусок vDom вниз через слоты на два уровня =) Короче, у меня это актуальная головоломка.
Александр же рассказал о том, как они организуют хранилище на основе Vuex, и этот (весьма интересный) подход, ИМХО, совершенно не завязан на хранение данных именно для форм — выбор todoMvc для иллюстрации эту мысль подтверждает. Но тем интереснее было бы посмотреть, как будет выглядеть реализация этой модели не на плоском списке, а на типичной ынтерпрайзной форме со вложенными группами полей, генерируемых из релейшнов, с хитрой валидацией и изысканными элементами UI :)
2) Доклад Александра Майорова был хорош и, как мне показалось, вызвал ажиотаж среди присутствующих ангулярщиков, реактщиков и прочих, кто Vue еще не щупал, но активно присматривается. Александр рассказал историю личного пути к Vue, довольно честно обозрел вообще развитие фронтенд-мысли за последние 5 лет, ну и, надеюсь, многих замотивировал пробовать.
Однако тема все-таки не была раскрыта: как в готовом проекте заменить jQuery на Vue нам не рассказали =( Александр лишь продемонстрировал, что порог входа действительно очень низкий, можно подключить Vue на страницу из CDN и немедленно начать колбасить, отложив настройку вебпака до лучших времен.
Но это для нового проекта. А для готового, подозреваю, эта задача вообще не очень решается. Все-таки jQuery — это в первую очередь удобная манипуляция DOM-деревом, но для готовки дерева с нуля он не предназначен. Там, где есть много jQuery-кода (и сопутствующей скорби), обычно верстка приходит откуда-то снаружи, чаще всего HTML рисует серверный шаблонизатор типа Twig, а jQuery «оживляет» результат. В то же время Vue (как и любой из «большой тройки») может управлять только тем отображением, которое сам и нарисовал (потому что, собственно, нету «управления», есть перерисовка). Это значит, что:
1) придется переписывать шаблоны (хорошо, если они хотя бы не «нейтив похапе»),
2) придется учить сервер отдавать JSON (хорошо, если в серверные шаблоны приходят «отупевшие» структуры, а не полноценные модельки, которые шаблон дергает за методы).
Оба этих занятия не из приятных, опасности таят великие, а профит ну такой (оно же работает, правда?).
Случаи бывают разными, но в целом я бы для проектов «с историей» рекомендовал такую тактику избавления от «истории»:
1) не ставить задачу «избавиться от jQuery» (бизнес не оценит),
2) но начать делать новые экранчики на Vue,
2) и когда надо переработать какой-нибудь старый экранчик — тоже внедрять Vue.
И надо понимать, что это требует значительного уменьшения связности в коде на разных уровнях — от бэкенда до CSS. Это полезно, но одним махом не делается.
3) Александр Сафт рассказал о поиске удобного способа управления состоянием. Мне доклад очень понравился. Вообще гораздо интереснее слушать про решения не в вакууме, а в контексте того, как они появились, какие проблемы приходилось решать, на какие компромиссы идти. Это учит нас критически смотреть в том числе и на общепринятые подходы, периодически спрашивать себя, а действительно ли мне вот это нужно, а хочу ли я писать вот такой код только потому, что так в мануале написано, или можно сделать проще?
Отдельно стоит заметить, что «оборачивание» Vuex или его замена на нечто «с человеческим лицом» — вообще прослеживаемая тенденция. Эта часть экосистемы, на мой взгляд, действительно выглядит слегка чужеродной, как минимум стилистически. Думаю, в ближайшее время мы еще увидим много интересного в этом направлении.
4) Григорий «Сюрприз-сюрприз» Петров в хорошем темпе представил обзор Nuxt. Без жести, но с понятными примерами и по-честному. По крайней мере я наконец понял область применения этой штуки, это ценно =)
Секция вопросов к этому докладу тоже была весьма интересной. Особо отмечу мысль о том, что для проектов со сложностью выше определенного уровня, нужно быть готовым переходить на самописные решения, потому что у готовых запас гибкости не бесконечный, а впихивать невпихуемое — иногда ощутимо дороже. Это было сказано про SSR, но можно обобщить.
Когда появится следующая задачка класса RAD, постараюсь вспомнить про Nuxt.
**
Подводя итог: митап удался, организация на 5+, контент на 4+ на мой вкус (хотелось бы больше хардкора, но это кому как). Респекты всем, надо продолжать =)
Жаждя кровавых подробностей, нагуглил только вот это:
FYI, we’ve been receiving a spam from “developers” of a fork of SphinxSearch claiming your development have stalled. That’s not nice of them.
@SphinxSearch user, yep, thanks for the report. I’m investigating this. At the moment, looks like some of the ex-employees decided that it’s quite appropriate not just to keep Sphinx internal information (like those emails subscribed to the mailing list) after leaving Sphinx for a competitor (silently, by the way, and while retaining access to Sphinx servers during the “pause mode” that we had), but also to use it this way. Well. Their actions kinda speak for themselves. :)
Я бы, кстати, тоже на досуге погонял 3.0, но увы:
Where are the commits? Not public. Mostly in private branches, both on Github, and locally.
В общем расскажите, чего вообще творится, а то у нас тут некий информационный вакуум, слышал даже мнение, что Сфинкс 3 это типа как Перл 6 +)
Я вам не скажу за весь MVC, но как минимум V на фронтенде нужен, если:
1) пофиг на поисковики,
2) а бэкендщики не хотят делать HTML, они хотят фыр-фыр-фыр хайлод, выбирать NoSQL, сетапить Docker и поднимать REST API.
Старый добрый jQuery не очень умеет делать V из REST API.
используем БЭМ-методологию не в полной реализации, исключая из нее миксы
Видимо, имеются ввиду только миксы «блок — блок»? Потому что без миксования «элемент — блок» не понятно, как располагать компоненты (оборачивать?). Вы вроде миксуете:
ничто не мешает вам сделать «олдскульный» сайт, используя только HTML и JavaScript
Дело в пальцевой механике: если кодер пишет в основном на es6, он рано или поздно на автопилоте зафигачит в «олдскульный» JavaScript что-то типа let {foo, bar} = baz и даже не заметит (потому что сидит в последнем Хроме). В рантайме «новомодный зоопарк» жрать не просит, так зачем отказываться от привычного процесса?
Ну да, оно так и задумывалось, потому что и nodejs, и npm придуманы для работы в серверном окружении, и там эта конструкция вполне соответствует условному require/require-dev из композера. Но в случае, описанном в статье, все вполне однозначно: либо на сервер попадает готовый бандл, и там тогда тупо нет node_modules (то есть ни moment.js, ни вебпака). Либо оно там же и собирается, и тогда там будет и вебпак, и moment.js.
Я не призываю все пихать в dependencies, порядок это вообще хорошо. Просто надо понимать, как оно работает, боюсь из статьи динозавр бы понял не совсем правильно +)
Обратите внимание на аргумент --save-dev — он сохраняет бандлер как зависимость среды разработки, так что она не понадобится на production-сервере.
Это как? Если на проде нет сборки, то там и moment.js не понадобится. Если есть сборка, она без бандлера не заработает.
На самом деле отличие в другом: если кто-то решит использовать ваш пакет как зависимость, ваши зависимости из devDependencies не будут подтягиваться в его node_modules.
По сути, мы просим webpack найти все .js-файлы (за исключением лежащих в папке node_modules) и применить babel-транспилирование
Мы не просим вебпак искать файлы. Мы ему объясняем что делать при импорте js-файла. В вашей формулировке получается что-то типа gulp.src('src/*.js'), но вебпак так не работает =)
Кстати, когда-то давно мы в конторе много писали на XSLT, и мне неоднократно приходилось обучать юных падаванов его основам. Так вот, ВСЕХ очень напрягал именно тот факт, что шаблон генерирует на выход дерево узлов (и, соответственно, ругается на незакрытые теги), а не последовательность букв. То есть, ожидали ровно обратного.
Для начала о задаче с акциями. Упрощу: [*actionsids*] заполняется вручную. Списываем нужные айдишники из дерева ресурсов через запятую. Если параметр не заполнен, не выводится ничего. Всё просто.
А если все-таки не упрощать? Или это вполне «продуктовый» вариант? Вы даете заказчикам вносить ID через запятую руками, правда? o_0
Я считаю преступлением против заказчика писать так, что ему потребуется выделенный сервер.
На шареде заказчик попадает в зависимость от соседей. Это может очень неожиданно проявиться, как бы вы там ни писали свой код.
Насчёт инфоблоков «Битрикса». В их терминологии это отдельный модуль для неких однотипных данных.
Ну, плюс-минус так. И разве это хоть отдаленно похоже на то, что называется инфоблоком у нас? Чем, интересно?
Примечательно, что под каждый инфоблок создаётся отдельная таблица в БД. В результате то, что можно было бы реализовать в паре таблиц, использует кучу таблиц и тонну однотипного говнокода.
Раньше как раз была пара таблиц (четыре, если точнее). Называется EAV. И работало оно так себе. Не понимаете почему? Ок, ну напишите на бумажке какой-нибудь запрос с фильтром + сортировкой + группировкой на такую схему. Лет пять назад они ввели обычные «горизонтальные» таблицы как альтернативный способ хранения. Сейчас не знаю, но судя по вашим словам, его сделали основным.
Как устройство таблиц влияет на количество однотипного кода — вообще не понимаю. Если только не писать все запросы руками, но вроде бы за такое сейчас бьют по рукам.
Не будет другой таблицы. Фактически для работы модуля понадобятся только системные таблицы. В результате в базе не хранится куча однотипных таблиц
Дайте угадаю. Вы большую часть своих клиентов посадили на какой-то супер-дешевый шаред, у которого есть ограничение на кол-во таблиц! А, или лучше: вы их засунули в один аккаунт, которому доступна одна БД, и разруливаете на префиксах! Тогда понятно, почему мысль о новых таблицах вас так пугает.
Серьезно, почитайте про entity-attribute-value: это подход для довольно специфических задач, и среди его преимуществ уж точно нет скорости.
Акции в данном случае берутся из ресурсов, количество, местоположение в иерархии и содержимое которых может быть каким угодно. [*actionsids*] — строка айдишников ресурсов через запятую. К каждой категории могут быть привязаны какие угодно айдишники. В MODX, кстати, это реализуется предельно просто на уровне тех же сниппетов. В MODX, надо отдать должное этой системе, при желании реализуется всё, вообще всё. И совсем не обязательно тоннами говнокода.
Все равно не понимаю =)
1. [*actionsids*] — это свойство текущей страницы, правильно? Как оно заполняется, на уровне интерфейса? Что нужно, чтобы добавить акцию к категории? Найти нужный айдишник и вписать в текстовое поле после запятой?
2. Если категория — не текущая страница, а одна из родительских (например, мы смотрим страницу товара) — можно ли достать айдишники ее акций, если да, то как?
впаривать ему выделенный сервер только потому, что мне лень написать 20 строк кода вместо 10, мне совесть не позволяет
Если бы выделенный сервер действительно чудесным образом позволял писать вдвое меньше кода, не пользоваться этой возможностью было бы преступлением против заказчика.
Если Ваша CMS потребляет порядочно ресурсов, тогда её в лучшем случае ждёт судьба «Битрикса».
Не худшая судьба, если смотреть на метрики: 3-е место по рунету среди всех систем, включая бесплатные, и первое с запасом среди платных.
Кстати, идея инфоблоков не оттуда ли взята? =)
Напомните, пожалуйста, что такое «инфоблок» в их терминологии.
Деструктивная секта =) Это же просто
<закончил ворчать>
Неплохо, но в 2к20 уже не достаточно — внедряйте кроссрассовость и кроссориентационность!
По теме: воронка выглядит слегка незаконченно без шага «оффер — согласие».
1) Выступление Александра Башкирцева было интересным, но не очень понятным =) Уловить мысль получилось, только почитав и пощелкав демо-код с включенным vue-плагином. Демонстрация и разбор кода, видимо, не влезли в регламент. Кто еще не ознакомился — ознакомьтесь обязательно: github.com/abashkirtsev/forms-example
Меня слегка сбило с толку название доклада, я скорее надеялся послушать про организацию верстки. Часто, особенно в CRUD-приложениях, верстать формы руками не хочется, потому что их много и они плюс-минус похожие. Можно взять генератор типа такого: github.com/vue-generators/vue-form-generator — и радоваться, пока не понадобится прикрутить что-то кастомное куда-то вглубь пирога «форма — строчки — поля». А когда понадобится — чесать репу, как бы так заинжектить нужный кусок vDom вниз через слоты на два уровня =) Короче, у меня это актуальная головоломка.
Александр же рассказал о том, как они организуют хранилище на основе Vuex, и этот (весьма интересный) подход, ИМХО, совершенно не завязан на хранение данных именно для форм — выбор todoMvc для иллюстрации эту мысль подтверждает. Но тем интереснее было бы посмотреть, как будет выглядеть реализация этой модели не на плоском списке, а на типичной ынтерпрайзной форме со вложенными группами полей, генерируемых из релейшнов, с хитрой валидацией и изысканными элементами UI :)
2) Доклад Александра Майорова был хорош и, как мне показалось, вызвал ажиотаж среди присутствующих ангулярщиков, реактщиков и прочих, кто Vue еще не щупал, но активно присматривается. Александр рассказал историю личного пути к Vue, довольно честно обозрел вообще развитие фронтенд-мысли за последние 5 лет, ну и, надеюсь, многих замотивировал пробовать.
Однако тема все-таки не была раскрыта: как в готовом проекте заменить jQuery на Vue нам не рассказали =( Александр лишь продемонстрировал, что порог входа действительно очень низкий, можно подключить Vue на страницу из CDN и немедленно начать колбасить, отложив настройку вебпака до лучших времен.
Но это для нового проекта. А для готового, подозреваю, эта задача вообще не очень решается. Все-таки jQuery — это в первую очередь удобная манипуляция DOM-деревом, но для готовки дерева с нуля он не предназначен. Там, где есть много jQuery-кода (и сопутствующей скорби), обычно верстка приходит откуда-то снаружи, чаще всего HTML рисует серверный шаблонизатор типа Twig, а jQuery «оживляет» результат. В то же время Vue (как и любой из «большой тройки») может управлять только тем отображением, которое сам и нарисовал (потому что, собственно, нету «управления», есть перерисовка). Это значит, что:
1) придется переписывать шаблоны (хорошо, если они хотя бы не «нейтив похапе»),
2) придется учить сервер отдавать JSON (хорошо, если в серверные шаблоны приходят «отупевшие» структуры, а не полноценные модельки, которые шаблон дергает за методы).
Оба этих занятия не из приятных, опасности таят великие, а профит ну такой (оно же работает, правда?).
Случаи бывают разными, но в целом я бы для проектов «с историей» рекомендовал такую тактику избавления от «истории»:
1) не ставить задачу «избавиться от jQuery» (бизнес не оценит),
2) но начать делать новые экранчики на Vue,
2) и когда надо переработать какой-нибудь старый экранчик — тоже внедрять Vue.
И надо понимать, что это требует значительного уменьшения связности в коде на разных уровнях — от бэкенда до CSS. Это полезно, но одним махом не делается.
3) Александр Сафт рассказал о поиске удобного способа управления состоянием. Мне доклад очень понравился. Вообще гораздо интереснее слушать про решения не в вакууме, а в контексте того, как они появились, какие проблемы приходилось решать, на какие компромиссы идти. Это учит нас критически смотреть в том числе и на общепринятые подходы, периодически спрашивать себя, а действительно ли мне вот это нужно, а хочу ли я писать вот такой код только потому, что так в мануале написано, или можно сделать проще?
Отдельно стоит заметить, что «оборачивание» Vuex или его замена на нечто «с человеческим лицом» — вообще прослеживаемая тенденция. Эта часть экосистемы, на мой взгляд, действительно выглядит слегка чужеродной, как минимум стилистически. Думаю, в ближайшее время мы еще увидим много интересного в этом направлении.
4) Григорий «Сюрприз-сюрприз» Петров в хорошем темпе представил обзор Nuxt. Без жести, но с понятными примерами и по-честному. По крайней мере я наконец понял область применения этой штуки, это ценно =)
Секция вопросов к этому докладу тоже была весьма интересной. Особо отмечу мысль о том, что для проектов со сложностью выше определенного уровня, нужно быть готовым переходить на самописные решения, потому что у готовых запас гибкости не бесконечный, а впихивать невпихуемое — иногда ощутимо дороже. Это было сказано про SSR, но можно обобщить.
Когда появится следующая задачка класса RAD, постараюсь вспомнить про Nuxt.
**
Подводя итог: митап удался, организация на 5+, контент на 4+ на мой вкус (хотелось бы больше хардкора, но это кому как). Респекты всем, надо продолжать =)
Я бы, кстати, тоже на досуге погонял 3.0, но увы:
В общем расскажите, чего вообще творится, а то у нас тут некий информационный вакуум, слышал даже мнение, что Сфинкс 3 это типа как Перл 6 +)
1) пофиг на поисковики,
2) а бэкендщики не хотят делать HTML, они хотят
фыр-фыр-фырхайлод, выбирать NoSQL, сетапить Docker и поднимать REST API.Старый добрый jQuery не очень умеет делать V из REST API.
Видимо, имеются ввиду только миксы «блок — блок»? Потому что без миксования «элемент — блок» не понятно, как располагать компоненты (оборачивать?). Вы вроде миксуете:
button button_size_xl button_theme_alfa-on-white attach__buttonДело в пальцевой механике: если кодер пишет в основном на es6, он рано или поздно на автопилоте зафигачит в «олдскульный» JavaScript что-то типа
let {foo, bar} = bazи даже не заметит (потому что сидит в последнем Хроме). В рантайме «новомодный зоопарк» жрать не просит, так зачем отказываться от привычного процесса?Я не призываю все пихать в dependencies, порядок это вообще хорошо. Просто надо понимать, как оно работает, боюсь из статьи динозавр бы понял не совсем правильно +)
Это как? Если на проде нет сборки, то там и moment.js не понадобится. Если есть сборка, она без бандлера не заработает.
На самом деле отличие в другом: если кто-то решит использовать ваш пакет как зависимость, ваши зависимости из devDependencies не будут подтягиваться в его node_modules.
Мы не просим вебпак искать файлы. Мы ему объясняем что делать при импорте js-файла. В вашей формулировке получается что-то типа
gulp.src('src/*.js'), но вебпак так не работает =)ну так package.json в студию, мы вам расскажем ))
Вообще я не очень понимаю, как это можно конструктивно обсуждать вне контекста конкретных проектов, которые пилят участники дискуссии.
Правда, в те времена балом правил Smarty :)
А если все-таки не упрощать? Или это вполне «продуктовый» вариант? Вы даете заказчикам вносить ID через запятую руками, правда? o_0
На шареде заказчик попадает в зависимость от соседей. Это может очень неожиданно проявиться, как бы вы там ни писали свой код.
Ну, плюс-минус так. И разве это хоть отдаленно похоже на то, что называется инфоблоком у нас? Чем, интересно?
Раньше как раз была пара таблиц (четыре, если точнее). Называется EAV. И работало оно так себе. Не понимаете почему? Ок, ну напишите на бумажке какой-нибудь запрос с фильтром + сортировкой + группировкой на такую схему. Лет пять назад они ввели обычные «горизонтальные» таблицы как альтернативный способ хранения. Сейчас не знаю, но судя по вашим словам, его сделали основным.
Как устройство таблиц влияет на количество однотипного кода — вообще не понимаю. Если только не писать все запросы руками, но вроде бы за такое сейчас бьют по рукам.
Дайте угадаю. Вы большую часть своих клиентов посадили на какой-то супер-дешевый шаред, у которого есть ограничение на кол-во таблиц! А, или лучше: вы их засунули в один аккаунт, которому доступна одна БД, и разруливаете на префиксах! Тогда понятно, почему мысль о новых таблицах вас так пугает.
Серьезно, почитайте про entity-attribute-value: это подход для довольно специфических задач, и среди его преимуществ уж точно нет скорости.
Все равно не понимаю =)
1. [*actionsids*] — это свойство текущей страницы, правильно? Как оно заполняется, на уровне интерфейса? Что нужно, чтобы добавить акцию к категории? Найти нужный айдишник и вписать в текстовое поле после запятой?
2. Если категория — не текущая страница, а одна из родительских (например, мы смотрим страницу товара) — можно ли достать айдишники ее акций, если да, то как?
Если бы выделенный сервер действительно чудесным образом позволял писать вдвое меньше кода, не пользоваться этой возможностью было бы преступлением против заказчика.
Не худшая судьба, если смотреть на метрики: 3-е место по рунету среди всех систем, включая бесплатные, и первое с запасом среди платных.
Напомните, пожалуйста, что такое «инфоблок» в их терминологии.