попробуйте посмотреть примеры визуализации песен с несколькими инструментами
К примеру этот пример
Несколько инструментов можно расположить в 3д, что позволяет продемонстрировать сложную композицию на лету меняя громкость отдельных инструментов.
Мне кажется что это очень классная идея.
новый Enterprise development tools анонсирован уже очень давно, а воз и ныне там. Как временное решение прикрутили у себя https://github.com/xDrivenDevelopment/precommit1c но скажем так — супер удобной такая система не является. Скажем так — пока в основе обработок и конфигураций бинарный формат — не видать нам мерджей в гите.
На самом деле при повседневной текучке задач не сильно успеваешь задуматься куда мы идем.
Интересно разнести то что мы видим и используем в жизни в такую систему.
№0 Data files
Любимые всеми таблички Excel
№1 File-server
Ранее были очень популярные MS Access, FoxPro — базы данных интегрированные в приложение. Можно сказать что это движок базы данных с интерфейсом вшытым в нее.
№2 Local DB
В этом сегменте прошло мое отрочество — BDE и иже с ним.
№3 Client-Server
Большинство старых бизнес приложений, всё работающее в связке с MS SQL. Собственно большинство приложений работающих с локальной базой при росте количества пользователей мигрировали в этот режим работы.
№4 Three-tier
Большинство современных бизнес приложений (это в том числе и 1С и всевозможные клиенты к разнообразным промышеленным системам). Это просто колосальный по обьемам пулл приложений, обслуживающих заводы, общепит, производства, трубопроводы...
№5 Web-client
тут живет большая часть вэба — всевозможные php с wordpress (с колосальной долей сайтов в интернете)
№6 Web 2.0
мир открытый для меня первыми версиями gmail, с jquery и вереницами ajax запросов. Все сайты из №5 которые научились взаимодействовать с пользователями. Те же форумы, трекеры.
№7 SPA/WebApp
тут мы живем сейчас, Angular 2, React. Весьма уютное место на самом деле.
на самом деле мы уже пытаемся запустится с новым, если получится то выложим к концу недели обновление с работающим новым Universal в компоненты уже.
+ скоро запустим эксперимент с индексацией (делаем мультистор сайта с magento на наших компонентах — сравним индексацию)
мы у себя используем docker-gen: https://github.com/jwilder/nginx-proxy к нему ест контейнер компаньон, который занимается выпуском и продлением LE сертификатов. То есть он смотрит какие запущены контейнеры на машине, читает их переменные окружения, смотрит в них vhosts которые нужно создать и собственно поднимает прокси ко всем внутренним контейнерам. Это оказалось невероятно удобным способом запустить к примеру 15 разных WP (с разными версиями PHP), вместе с парой приложений на nodejs в рамках одной машины раскидав их на разные домены. Однако у схемы с LE оказался неожиданный минус. Я сделал стэйдж таким образом, при наличии 15 сайтов мы уперлись в rate limit от LE. Слишком много сертификатов выдано на домен и все. Все попытки написать LE запрос на увеличение лимитов по домену (есть у них форма на сайте) ни к чему не привели. Так что если у вас много поддоменов — рекомендую задуматься о покупке иного wildcard.
Да. Сначла мы работали на MEAN стэке, потом пару раз столкнулись с Parse. У нас ранее был проект с закрытым кодом, в который мы через GTM инжектили скрипты для AB тестов, промоакций, трекинга событий и просто банальна фиксы дизайна. Соотвтетственно нам нужно было решение для храниния настроек и состояний без бд. Потом появился FireBase с возможностью подписки на изменения что позволило существенно расширить функционал. А далее мы выяснили что FireBase был куплен Google, который ни о ком не заботясь сделал релиз 3й версии, который заставил нас много всего переписать. Собственно далее мы стали его использовать как бэк для мобильных приложений, чтобы не заботится о масштабировании. Пототм для админ панелей. А сейчас вообщем-то используем для большинства новых проектов. Плюс недавний релиз функций может позволить нам избавится от oserver сервисов.
Ну и у firebase есть бесплатный хостинг — что нравистя многим клиентам, да и нам — настроил и забыл.
Собственно благодаря Universal надеюсь в скором времени произойдет перелом в сторону клиентских проектов, а не только админок. (Хотя и они никуда не уйдут — уже сейчас сделали пару админок на angular 2 + firebase и очень довольны).
Для маркетинга и аналитики выбран чуть иной путь. Все данные из firebase переливать в bigquery. Заказы, клики, просмотры, все-все. А дале по датасету в bigquery можно делать анализ и для любителей красоты и дашбордов есть google data studio. В нем удобно именно маркетологам работать.
Да, для работы с бд есть DataAbstractionLayer — который как раз и дает такое API и должен позволить нам в случае необходимости заменить firebase на couchdb к примеру. А так да — есть observer server сейчас, который загружает плагины, которые уже оформляют подписки на нужные события и отправляют их в интегрированные сервисы. Пример такого сервера будет в стартере в следующем месяце.
Соберетесь делать интернет магазин — милости просим :) мы будем стараться помогать всем пользователям компонент, сейчас сделали документацию на базе compodoc, далее в планах стартер для желающих быстро запустить демо магазин (правда быстро будет включать в себя докер, что увы как оказалось многих может остановить)
Про сами компоненты чуть позже будет отдельная статья.
Сейчас все наши магазины это витрины к разнообразным учетным системам. То есть в бэкэнд данные попадают через демон импортер из 1c\google sheets\yandex.yml или иной системы. Общая концепция состоит в том что ненужно создавать еще одну монстроадинку с складом\налогами\доставкой, а интегрироваться с существующими решениями для управления складом и учетом. Чаще всего у клиентов уже есть какие-то способы управления\организациию Для посмотреть\поиграться или просто маленького магазина проще всего google sheets. Как оказалось небольшие магазины и так ведут в нем склад и продажи, так что им удобно — просто теперь данные из sheets синхронизируются с магазином (+попадаются просто зубодробильные формулы по расчету цены реализации).
А вот аналитика помимио стандартных google analytics собирается в бд, отдельно по всем действиям пользователя — устройства, сессии, клики, показы и т.д.
По поводу платежных систем — пишем универсальные модули по мере запросов от клиентов (stripe, 2checkout, w1 etc). С ними проблем нет. По поводу систем доставки — пока все статичные, будут запросы на какие-то сервисы — сделаем и с ними интеграцию.
Вообще вся корзина это просто метод композиции из модулей платежек и способов доставки, просто с учетом экспортируемых ими требований (к примеру PayPal не требует выбора адреса доставки, а наложенный платеж Новой Почтой не требует указания ничего кроме адреса)
Даже крупнейшие магазины электронной коммерции по-прежнему выглядят как куча статических страниц. Для пользователя это нескончаемый цикл кликов, ожиданий и перезагрузки страниц.
найти разработчика на Angular 2 в скором времени будет проще чем найти толкового разработчика Magento. Как раз потому что область применения Angular шире чем область применения Magento.
И статья не об этом, а о новой технологии которая позволяет еще более расширить область применения Angular на сферу в которой он изначально не был применим из-за проблем с индексацией поисковиками.
Конечно, но вопросы по теме статьи приветствуются в первую очередь. Если у вас есть вопросы об Angular Universal и том как его применять в живых проектах — будем рады.
В статье описанны те грабли с которыми мы столкунулись — возможно вы можете подсказать нам на какие мы еще не напоролись в Angular Universal?
на самом деле нет — все компоненты в opensource. Второй Angular очень большой путь проделал по унификации и улучшению поддерживаемости, так что любой фронт разработчик знакомый с Angular сможет вносить правки в проект. А правки по оформлению может внести банально верстальщик за счет разделения кода шаблона и кода компонент.
Наше столкновение с Magento как раз показало что получается дорого и малость отстало с точки зрения фронтэнда. Конечно Magento2 уже дружит с Symfony, что безусловно пойдет ей на пользу (особенно в плане удешевления разработки под нее и уменьшения количества плохо написанных дополнений).
Вечный холиварный вопрос — Angular with React да будет кровь!..
Банально дешвеле стоимость владения и больше перееиспользуемость между проектами. Очень помогает RxJS в разработке. Ну и кончено удобство работы с Firebase из Angular. На данный момент иной нежели Firebase конеектор не предусмотрен. С появление Firebase Functions разработка других конекторов становится менее приоритетной.
Это все про 4й Angular, он не такой хайпный, и совсем-совсем новый. Учли всю ту боль с которой мы жили используя 1й Angular. Новый Angular совсем-совсем модульный. Собственно из-за этого он намного более похож на конструктор, более чем плагины в той же magento.
+ разрабатывать интерфейс на нем намного комфортнее чем в шаблонах того же prestashop\magento, за счет большей кастомизируемости и гибкости.
Скажем так — по всем параметрам, кроме SEO, удобство решения на Angular выше чем у класического написания шаблонов для magento\prestashop.
А про то как решается вопрос с SEO как раз и расказанно в статье.
Мы делаем магазины на Angular чтобы избежать постраничности, постоянных переходов — таким образом пользователю приятнее пользоваться сайтом. Поэтому мы ушли с PrestaShop\Magento в сторону разработки переиспользуемых компонент на Angular (только сразу на втором). А дальше мы из них собираем фронт выбирая те модули что нам нужны в конкретном магазине. Все модули независимы друг от друга, но есть связующее звено DAL — data abstraction layer, через которое происходит работа с backend. На github есть коннектор к firebase как бэкэнду. Вообще скоро планируется статья отдельно про firebase, а потом ещк именно про сами компоненты для интернет магазинов с примерами (к этому моменту надеюсь напишем starter-project).
https://github.com/rasa/vmware-tools-patches есть еще вот такой репозиторий. Он очень помогает при наличии зоопарка разных версий esxi и разных «необычных» проблем требующих патчей.
могу сказать что с функциональностью самого чата есть проблемы. К примеру передача параметров в чат. Она не работает для spa (Angular к примеру). То есть чат принимает только параметры заданные до его инициализации. Если же это spa — логин происходит далеко после загрузки. И чат благополучно игнорирует новые данные об Id/mail пользователя.
не откажусь от промо кода.
по поводу ns серверов — вопрос один, на сколько датацентров сейчас разнесен этот функционал? Ведь ns сервер это по факту точка отказа для всего сайта. В свое время пережив пару падений ns серверов у хостеров прочно пересели на cloudflare на всех проектах (благо там есть поддержка wildcard записей, как у вас с этим кстати?)
попробуйте посмотреть примеры визуализации песен с несколькими инструментами
К примеру этот пример
Несколько инструментов можно расположить в 3д, что позволяет продемонстрировать сложную композицию на лету меняя громкость отдельных инструментов.
Мне кажется что это очень классная идея.
На самом деле при повседневной текучке задач не сильно успеваешь задуматься куда мы идем.
Интересно разнести то что мы видим и используем в жизни в такую систему.
№0 Data files
Любимые всеми таблички Excel
№1 File-server
Ранее были очень популярные MS Access, FoxPro — базы данных интегрированные в приложение. Можно сказать что это движок базы данных с интерфейсом вшытым в нее.
№2 Local DB
В этом сегменте прошло мое отрочество — BDE и иже с ним.
№3 Client-Server
Большинство старых бизнес приложений, всё работающее в связке с MS SQL. Собственно большинство приложений работающих с локальной базой при росте количества пользователей мигрировали в этот режим работы.
№4 Three-tier
Большинство современных бизнес приложений (это в том числе и 1С и всевозможные клиенты к разнообразным промышеленным системам). Это просто колосальный по обьемам пулл приложений, обслуживающих заводы, общепит, производства, трубопроводы...
№5 Web-client
тут живет большая часть вэба — всевозможные php с wordpress (с колосальной долей сайтов в интернете)
№6 Web 2.0
мир открытый для меня первыми версиями gmail, с jquery и вереницами ajax запросов. Все сайты из №5 которые научились взаимодействовать с пользователями. Те же форумы, трекеры.
№7 SPA/WebApp
тут мы живем сейчас, Angular 2, React. Весьма уютное место на самом деле.
№8 PWA & Mobile
Сюда мы стремися попасть, добавляя PouchDB, FireBase etc.
Database-centric P2P Network — нечто похожее предсавляет из себя Эфириум с его смарт-контрактами
— Write documentation for core API (In Progress)
на самом деле мы уже пытаемся запустится с новым, если получится то выложим к концу недели обновление с работающим новым Universal в компоненты уже.
+ скоро запустим эксперимент с индексацией (делаем мультистор сайта с magento на наших компонентах — сравним индексацию)
Ну и у firebase есть бесплатный хостинг — что нравистя многим клиентам, да и нам — настроил и забыл.
Для маркетинга и аналитики выбран чуть иной путь. Все данные из firebase переливать в bigquery. Заказы, клики, просмотры, все-все. А дале по датасету в bigquery можно делать анализ и для любителей красоты и дашбордов есть google data studio. В нем удобно именно маркетологам работать.
Да, для работы с бд есть DataAbstractionLayer — который как раз и дает такое API и должен позволить нам в случае необходимости заменить firebase на couchdb к примеру. А так да — есть observer server сейчас, который загружает плагины, которые уже оформляют подписки на нужные события и отправляют их в интегрированные сервисы. Пример такого сервера будет в стартере в следующем месяце.
Соберетесь делать интернет магазин — милости просим :) мы будем стараться помогать всем пользователям компонент, сейчас сделали документацию на базе compodoc, далее в планах стартер для желающих быстро запустить демо магазин (правда быстро будет включать в себя докер, что увы как оказалось многих может остановить)
Сейчас все наши магазины это витрины к разнообразным учетным системам. То есть в бэкэнд данные попадают через демон импортер из 1c\google sheets\yandex.yml или иной системы. Общая концепция состоит в том что ненужно создавать еще одну монстроадинку с складом\налогами\доставкой, а интегрироваться с существующими решениями для управления складом и учетом. Чаще всего у клиентов уже есть какие-то способы управления\организациию Для посмотреть\поиграться или просто маленького магазина проще всего google sheets. Как оказалось небольшие магазины и так ведут в нем склад и продажи, так что им удобно — просто теперь данные из sheets синхронизируются с магазином (+попадаются просто зубодробильные формулы по расчету цены реализации).
А вот аналитика помимио стандартных google analytics собирается в бд, отдельно по всем действиям пользователя — устройства, сессии, клики, показы и т.д.
По поводу платежных систем — пишем универсальные модули по мере запросов от клиентов (stripe, 2checkout, w1 etc). С ними проблем нет. По поводу систем доставки — пока все статичные, будут запросы на какие-то сервисы — сделаем и с ними интеграцию.
Вообще вся корзина это просто метод композиции из модулей платежек и способов доставки, просто с учетом экспортируемых ими требований (к примеру PayPal не требует выбора адреса доставки, а наложенный платеж Новой Почтой не требует указания ничего кроме адреса)
И статья не об этом, а о новой технологии которая позволяет еще более расширить область применения Angular на сферу в которой он изначально не был применим из-за проблем с индексацией поисковиками.
В статье описанны те грабли с которыми мы столкунулись — возможно вы можете подсказать нам на какие мы еще не напоролись в Angular Universal?
Наше столкновение с Magento как раз показало что получается дорого и малость отстало с точки зрения фронтэнда. Конечно Magento2 уже дружит с Symfony, что безусловно пойдет ей на пользу (особенно в плане удешевления разработки под нее и уменьшения количества плохо написанных дополнений).
Банально дешвеле стоимость владения и больше перееиспользуемость между проектами. Очень помогает RxJS в разработке. Ну и кончено удобство работы с Firebase из Angular. На данный момент иной нежели Firebase конеектор не предусмотрен. С появление Firebase Functions разработка других конекторов становится менее приоритетной.
+ разрабатывать интерфейс на нем намного комфортнее чем в шаблонах того же prestashop\magento, за счет большей кастомизируемости и гибкости.
Скажем так — по всем параметрам, кроме SEO, удобство решения на Angular выше чем у класического написания шаблонов для magento\prestashop.
А про то как решается вопрос с SEO как раз и расказанно в статье.
Собственно мы сейчас тоже пробуем сделать аналогичное решение (уже месяца 3-4 в nodeart.io), connect skype: nosovk
Есть http://helpdeskdemo.sibirix.ru/ но нигде нет к нему пароля :(
по поводу ns серверов — вопрос один, на сколько датацентров сейчас разнесен этот функционал? Ведь ns сервер это по факту точка отказа для всего сайта. В свое время пережив пару падений ns серверов у хостеров прочно пересели на cloudflare на всех проектах (благо там есть поддержка wildcard записей, как у вас с этим кстати?)