Комментарии

Работаем на DST Platform отличная система. Особенно мощно реализована панель управления, максимально простая но при этом многофункциональная, интуитивно понятна и сосредоточена на процессе управления контентом и бизнес процессами.

Также радуют что в DST Platform очень тонко можно настроить права доступа. Каждый пользователь сайта может принадлежать к одной или нескольким группам. Система прав групп пользователей достаточно гибкая, чтобы настроить доступ буквально к любому действию. Также в комплекте есть механизм автоматического перевода между группами для автоматического повышения или понижения привилегии пользователя по заданным администратором условиям.

Вообщем для маркетплейсов, экосистем и социальных систем незаменимый фреймворк.

Работаем на DST Platform отличная система. Особенно мощно реализована панель управления, максимально простая но при этом многофункциональная, интуитивно понятна и сосредоточена на процессе управления контентом и бизнес процессами.

Также радуют что в DST Platform очень тонко можно настроить права доступа. Каждый пользователь сайта может принадлежать к одной или нескольким группам. Система прав групп пользователей достаточно гибкая, чтобы настроить доступ буквально к любому действию. Также в комплекте есть механизм автоматического перевода между группами для автоматического повышения или понижения привилегии пользователя по заданным администратором условиям.

Вообщем для маркетплейсов, экосистем и социальных систем незаменимый фреймворк.

затем же, зачем при разработке используется ide, сниппеты, библиотеки, и прочее.

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

В разработке сайта прототипирование — это этап, который следует за исследованием, перед созданием дизайна.

В студии DST Global мы начали использовать прототипы, потому что поняли, что все комментарии заказчика касаются не того, что ему не нравится цвет или размер элементов. Как правило, правки связаны с тем, что забыли про какую-то сущность: телефон, фильтр по каталогу, блок с новостями и т.п. В основном, большинство комментариев касались функциональности. Поэтому, чтобы не тратить время на перерисовку, мы ввели промежуточный этап — прототипирование.

И конечно самое главное — хорошо, продуманно составленный прототип является полноценным каркасом сайта, на который потом легко «надевается» дизайн.

Есть очень большая тема про треугольник project-managmenta, работу с заказчиком, разделение ответственности заказчика и исполнителя и прочая прочая. Эта тема достойна пожалуй вереницы статей, потому что это тема про боль и страдания современного it бизнеса :)

Если из этой большой темы выдернуть маленький кусочек который как то коррелирует с вашим описанием рабочего процесса, то можно сказать следующее. В целом да, в идеале бы так оно и было, но практика и даже теория pm'та говорит о том что невозможно зафиксировать scope работ, бюджет проекта и время выполнения одновременно так, чтобы проект был завершен успешно. Оттуда вытекают платные чейндж реквесты, fail сроков, быстрая трата денег с несделанным продуктом, несоответствие продукта и ожиданиям и так далее.

Scrum не про то, чтобы сделать команде хорошо и всё. Scrum — не фреймворк разработки, это фреймворк создания продуктов. Scrum больше про то, чтобы делать проекты успешными и заказчика довольным жизнью, а также обеспечивать востребованность продуктом. Работа команды и с командой это малая часть.

Интересно а почему дизайнеры вообще стали использовать прототипы? Раньше делали ведь просто дизайн и дальше разработку, UI/UX и прототипирование появилось сравнительно недавно если я не ошибаюсь

Для начала определимся с терминологией. В английском языке есть слова wireframe и prototype. В русском языке — сетка, прототип и живой прототип. Из-за трудностей с переводом, все время возникает путаница. Wireframe переводится как сетка. Но то, что мы называем сеткой — это grid. А то, что по-английски называется wireframe, мы называем прототипом. То, что у них prototype, мы называем «живой прототип» (который можно покликать).

От лица всей нашей компании хочу поблагодарить персонал ДСТ принимавший участие в работе над нашим новым маркетплейсом. У нас было свое представление будущего сайта и благодаря нормальному и плодотворному рабочему процессу со специалистами ДСТ получилось его создать. Мы реализовали то что хотели с вашей помощью! Спасибо за проделанную работу!

Edge на chromium поддерживает, а старый edge нет

Вот замечательная таблица со всеми (основными) видами типов веб-приложений

Мы обратились за ремонтом сайта в DST Global. Первое что приятно удивило это — удобное взаимодействие. Все пожелания по визуализации сайта были выполнены, в процессе обсуждались полезные рекомендации и оптимальные решения по структуре. Окончательный вариант выполнен в соответствии с техническим заданием. Спасибо

Спасибо специалистам DST, за то что ответственно подходят к работе и решению поставленных задач. За время совместной работы над нашей цифровой платформой, сотрудники компании показали себя высокими профессионалами, которые следят за качеством выполняемой работы и учитывают пожелания Заказчика. Выполнили работу все работы в установленные сроки.

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

Несколько слов поводу SPA и их «недостатках» (буду высказываться в контексте Vue.js)

1) Для SEO в мире SPA существует SSR (Server side rendering) — Nuxt.js.
Если кратко, то когда пользователь впервые обращается к сайту, то на стороне сервера делаются все необходимые запросы к API для получения данных + «раскрывается» вся html, выполняется еще куча различных действий и в итоге на клиент улетает уже развернутая html, со всеми необходимыми данными, а дальше web-приложение начинает работать как обычное SPA.

2) Производительность при первой инициализации сайта на стороне клиента (без использования SSR) действительно будет уступать многостраничным (MPA) приложением, но когда дела доходит до роутинга (переходам по страницам) выбору фильтров, оформления покупки и т.д. (AJAX), то SPA в десятки раз выигрывает по производительности у MPA приложений, т.к. время на отрисовку при каждом действии всей страницы (как в MPA) требуется гораздо больше, нежели чем SPA приложению (т.к. перерисовывается только то, что изменилось и не более того). Стоит помнить, что самая дорогая операция в вебе — это рендер / отрисовка

А если же использовать SPA + SSR, то MPA приложения проигрывают по производительности практически во всех аспектах.

Так же, с помощью SSR мы можем реализовывать следующую технику: загружать только те части js / css, которые необходимы для работы конкретного компонента, т.е. представьте, что у нас есть страница каталога с закрытой картой и с закрытыми фильтрами. Когда мы загружаем эту страницу, то у нас не подгружаются компоненты, связанные с картой и фильтрами (т.к. она закрыты) => размер страницы будет крайне мал, а когда человек включает карту или (и) фильтры, то у нас динамически со стороны сервера подгружаются эти самые компоненты (Code Splitting), крч мы подгружаем компоненты только тогда, когда в них есть необходимость.
И дополню, что Code Splitting работает не только для отдельных компонентов, но и для целых страниц, что очень сильно облегчает размер бандла => скорость отдачи web-приложения на сторону клиента.

3) Утечка памяти: если над SPA приложением работает (ют) квалифицированные разработчики, то я на 99.8% уверен в том, что подобной проблемы не возникнет, т.к. методы / тулзы для профилирования (анализа работы приложения) уже давным-давно вышли на новый уровень и сейчас не эпоха ie6, где люди дебажили (искали баги / ошибки) с помощью alert's. И непонятно, почему этот пункт отнесся именно к SPA, ведь в любом приложении, где есть хоть какая-то логика, может возникнуть подобная ситуация, ни?

4) Поддержка js — я хз, но мы сейчас не в 2001 году, и я никогда (на основе личного опыта) не видел подобных людей, у которых был бы отключен js (исключение — это Opera Mini или всякие proxy browser, доля которых 0.0001% (наобум)), да даже в том же Tor Browser уже по умолчанию включен js (просто знаю).
В дополнении к этому, могу сказать, что для этого в мире SPA, и не только — существует специальная техника, которая называется Graceful Degradation (можно так же посмотреть в сторону Progressive Enhancement, как делает VK и многие другие популярные платформы).

5) Про PWA / TWA даже писать не буду, т.к. для этого нужно писать отдельную статью о том, что в этой статье не так.

Для frontend developer'ов: я постарался выражаться не с точки зрения программиста, а с точки зрения «обывателя», чтобы всем было понятно, о чем я говорю, поэтому примите и простите.

Я смотрю требования в DST высокие даже к джунам, это грустно, я не дотягиваю даже до этого уровня, еще учится и учится

Всегда доводи начатое дело до конца.
Но в начале подумай: стоит ли оно того?
Необходимо ли это?
Чтобы потом без вариантов. Раз решив — иди до конца, иди, и останавливайся на передышку как можно меньше. Чем больше отдыхаешь — тем меньше хочется работать. И чем больше работаешь — тем меньше хочется отдыхать.
Всегда доводи начатое дело до конца.
Иначе мало того, что ерунда в итоге получится, так ещё и себя уважать перестанешь. Какое бы оправдание себе не придумал.

Очень хорошие, мотивирующие советы. Главный совет — доводите начатое до конца и все получится

Большое спасибо за подробную статью о SPA и MPA и в целом развитии веб приложений, это было очень интересно и познавательно.

Удобство все же вполне осязаемая штука. Если взять две системы и попробовать научить использовать их секретаршу, а потом еще предложить ей консультирование в течении месяца, то все становится довольно быстро понятным. Учить Joomla например будет весьма непросто. Люди просто забывают как там и что работает, как только закрывают ее больше чем на неделю. И посмотрите для примера MODx. Для понимания всех основных и необходимых возможностей управления уходит примерно 3-4 часа (включая последующие консультации).

Разумеется сначала человеку нужно разобраться в интерфейсе. Так вот скорость изучения как раз и зависит от удобства.

В общем-то правда, что данные CMS делаются программистами для программистов. Потому что именно программисты потом проводят внедрение этих систем, допилку напильником под нужды заказчика. У всех систем свои интерфейсы, так как слишком разная у всех концепция хранения, представления и управления информацией. Унифицированного ничего нет. Даже windows вам удобна только потому что вы к ней привыкли. А если посадить человека первый раз за компьютер, то интерфейс любой CMS будет ему не на много отличаться от интерфейса винды — также неудобен и незнаком.