Всем привет!
Сегодня хотел бы рассказать об одном решении самой частой проблемы в командной разработке, которое в итоге вылилось в целый npm пакет.
И как вы поняли, речь пойдёт о SEO анализаторе, инструменте, который поможет отлавливать SEO дефекты на разных стадиях разработки (и, конечно же, сохранить хорошие отношения с SEO специалистами ?).
Привет, Хабр!
Меня зовут Дмитрий Матлах. Я тимлид в AGIMA. Мы с коллегами обратили внимание, что в сообществе часто возникает вопрос о том, как совместить на одном проекте Bitrix-компоненты и реактивные фронтовые движки. Мы неоднократно сталкивались с подобными задачами, и поэтому я решил подробно рассказать, как мы их решаем. Думаю, если вы используете Bitrix-фреймворк в своих проектах, прочитать будет интересно. Ну и забегая вперед, если вы решаете те же задачи по-другому, то интересно в комментариях узнать поподробнее.
При разработке бизнес-логики приложений нужно продумать действия с множествами – с пересечением, разницей массивов или двойной разницей. Недостатки в этом алгоритме могут привести к рискам. Например, если вам нужно в реальном времени обработать объем данных, превышающий определенную границу, система может «тормозить» – до минуты и даже больше. Такие ситуации требуют лишнего расхода ресурсов, отталкивают пользователей и вызывают другие проблемы.
Рассмотрим один из способов, которым мы пользуемся в работе для устранения подобных негативных эффектов. Статья будет полезна как разработчикам с опытом, которые ищут новые способы оптимизации своих продуктов, так и новичкам, которые только погружаются в тему оптимизации.
Вы когда-нибудь работали над несколькими проектами и хотели иметь набор настраиваемых компонентов, которые можно было бы использовать во всех из них? Будь то работа или просто побочные проекты, набор компонентов, к которым вы можете обратиться, - отличный способ ускорить работу в новом или существующем проекте. Но что, если не все ваши проекты используют одну и ту же структуру пользовательского интерфейса? Или, что, если у вас есть тот, который вообще не использует какой-либо фреймворк JavaScript и полностью отрисован на сервере?
Как разработчик Vue, в идеале мы хотели бы просто использовать наш фреймворк для создания сложных пользовательских интерфейсов. Но иногда мы оказываемся в описанной выше ситуации, работая с другим фреймворком JavaScript, таким как React или Angular, или используя внутреннюю систему рендеринга, такую как Rails или Laravel. Как мы можем создать многоразовый пользовательский интерфейс для различных вариантов внешнего интерфейса?
В Vue 3.2 у нас теперь есть решение этой проблемы: веб-компоненты на базе Vue!
Всем привет! Меня зовут Артём и я разработчик в команде Operations & Support Tools. Наша команда занимается разработкой софта для взаимодействия поддержки с пользователями, с целью решения любых возникших у пользователей проблем.
В прошлый раз один из моих коллег рассказывал, как реализовано взаимодействие сервисов у нас в Платформе. Те, кто пропустили эту статью, могут найти её по ссылке. Сегодня я хочу рассказать про приложение, которое раскрыло возможности Contract API с новой стороны. Знакомьтесь, Contract UI.
VuePress представляет собой минималистичный генератор статичных сайтов, оптимизированный для написания технической документации.
Изначальной целью VuePress, была поддержка фреймворка Vue.js и сопутствующей инфраструктуры. Для примера, можно посмотреть любую документацию по Vue: Vue.js, Vue Router, Vuex, где применяется единый стиль, заложенный в основе VuePress.
В ходе статьи мы разберем архитектуру VuePress, разработаем базовое приложение и выложим на GitHub Pages.
Я нашёл только 3 статьи по Vite.js на Хабр, там были некие обзоры функционала и описание фишек данного инструмента.
Хорошо, тогда вопрос, что же это за инструмент такой и в чем преимущества использовать его при разработке? Если мы зайдем на официальный сайт - то здесь выделяется 6 основных фишек:
В этой статье пойдёт речь о том, как я пришёл к тому, чтобы взяться писать плагин, создающий на лету vue компоненты из самописных svg иконок во время сборки проекта, о том, как я это делал, и о том, что в итоге получилось.
Мне уже давно и прочно нравится мир Vue. Особенно завораживает скорость, с которой в нём рождаются новые возможности писать код более лёгким и понятным. Недавно появились Composition API, VueUse, Vite… По ходу освоения этих новых инструментов я нашёл шаблон Vitesse, буквально насыщенный удобными средствами — и для управления макетами (layout), и для маршрутизации, и для локализации и ещё для много чего… Возможно, есть смысл написать отдельный обзор этого арсенала по русски (чего в Интернете пока ещё нет). Но сейчас речь не об этом.
В этой небольшой статье мы с вами напишем свое простое приложение по типу "заказа еды". Само приложение если что будет статичным и здесь главный упор будет сделан на использование компонентов Vuetify и рассмотрение того как именно они работают. Также добавлю что здесь мы не будем рассматривать отдельную библиотеку Bootstrap Vue которую использует Vuetify чтобы строить гриды.
В 2018 решил освоить Vue.js, так, для общего развития, а как известно, лучший способ освоить язык/фреймворк/etc — начать писать. В голову пришла довольно простая идея, которая со временем выросла в довольно большой проект — онлайн сервис «Места», позволяющий создавать свои коллекции мест на карте, геометок, с подробной информацией о них. Собирать их в альбомы, сортировать в дереве папок, просматривать, редактировать, обмениваться с другими, открывать для просмотра другим пользователям сервиса. Привязывать к местам фотоальбомы, экспортировать свои библиотеки в файлы JSON и GPX (для навигаторов, например), импортировать в свои библиотеки места других людей.
Идея была проста. Есть множество средств создания фотоальбомов, музыкальных плейлистов — с описаниями, возможностью сортировки, ссылками, преферансом и барышнями. А похожей полноценной картографической реализации толком нет. По крайней мере, я не нашёл.
Представьте, что вы пошли с другом в поход. Каждый у себя в навигаторе смартфона отмечал какие-то интересные места — удобные стоянки, опасные пороги, прохождение которых описывал. Потом вернулись домой, и каждый остался при своих. Сервис позволяет собрать их вместе, слив оба набора в один, отсортировать, разложить по папкам, отредактировать описания в удобном интерфейсе на компе, добавить фотографии, ссылки, сделать при желании видимыми другим пользователям сервиса, экспортировать потом, в конце концов, для использования в навигаторах и т. д.
Проект свободный (https://github.com/assador/places, сам действующий сервис пока здесь: http://places.scrofa-tridens.ru). Сейчас в планах помимо API Яндекс.Карт, которые отвечают, собственно, за карту, подключить и другие — OSM, 2ГИС и пр. Хочу добавить возможность добавлять к местам не только фото-, но и видео-, и аудиоальбомы. Развивать структуру прав и ролей пользователей, их связь друг с другом на сервисе, расшаривать библиотеки в соцсети и пр. Короче, для меня штука интересная.
Примерно год назад фронтенд нашего проекта, в качестве фреймворка для которого используется Vue.js 2, дошел до состояния, хорошо описываемого словами "проще сжечь".
К тому времени наш нетипизированный корабль уже трещал по всем швам, и решено было убить сразу нескольких зайцев одним выстрелом: полностью перевести проект на TypeScript, внедрить Vue Composition API и решить проблемы валидации сложных форм.
А проблемы были. Vuelidate - отличная библиотека с массой готовых валидаторов и остается таковой до тех пор, пока мы имеем дело с, так сказать, плоскими формами - формами, не использующими вложенных компонентов, также требующих валидации. Vuelidate работает на уровне компонента, требует наличия миксина, содержит массу правил, которые нам не были нужны, но все равно тянулись в составе пакета, поддержка TypeScript и Composition API на тот момент отсутствовала, и мы не могли более с этим миритьcя.
Веб-приложение Qvault, в котором размещаются все мои курсы по кодированию, представляет собой одностраничное приложение, написанное на Vue 2, с планами перехода на Vue 3 в ближайшее время. Тем временем я обнаружил новое классное инструментальное приложение под названием Vite, которое предложило несколько вещей, привлекших мое внимание.
Эта статья — перевод оригинальной статьи Evan You "Vue 3.2 Released!"
Мы рады объявить о выпуске Vue.js 3.2 "Quintessential Quintuplets"! Этот релиз включает в себя множество значительных новых функций и улучшений производительности и не содержит критических изменений.
Эта статья — перевод оригинальной статьи Andy Li из Vue Mastery "Vue 3 Migration Changes: Replace, Rename, and Remove (Pt. 2)".
Команда Vue недавно выпустила долгожданный билд миграции для Vue 3. Если вы думали об обновлении своего приложения с Vue 2 до Vue 3, это то, что вам нужно.
Процесс обновления приложения до последней версии фреймворка может оказаться непростой задачей. Эта серия статей создана, чтобы упростить этот процесс.
Как лучше всего структурировать приложение Vue.js, чтобы оно масштабировалось и оставалось обслуживаемым и расширяемым по мере его роста? Этот вопрос я слышал неоднократно, и думаю, что один из ответов на него кроется в принципе предсказуемости. Когда речь идет о создании масштабируемого проекта, вы хотите, чтобы все в нем было максимально предсказуемо.
Что именно я подразумеваю под предсказуемостью? В самом простом смысле, это способность интуитивно перейти от запроса функции или сообщения об ошибке к тому месту в кодовой базе, где эта задача может быть решена. Более того, это возможность быстро узнать, к каким инструментам вы имеете доступ в этом месте кодовой базы, чтобы выполнить поставленную задачу.
Почему это важно? Вы наверняка сталкивались с ситуацией, когда получали в наследство проект или были введены в него, а затем при выполнении первой задачи открывали кодовую базу и думали: "Я даже не знаю, с чего начать!".
Возможно, вы даже имели дело с кодовой базой в течение некоторого времени и возникала та же мысль! Предсказуемая кодовая база максимально облегчает этот опыт, делая знакомство разработчиков с проектами более простым, а продолжение работы - более эффективным.
Стоит отметить, что, хотя предсказуемость возможна, ни один проект никогда не станет предсказуемым на 100%. Каждый проект, новый или существующий, имеет хотя бы небольшую кривую обучения. Также следует знать, что предсказуемость не означает, что кодовая база или приложение будут быстро понятны в целом. Многие крупномасштабные приложения просто слишком сложны, чтобы это было возможно, и потребуется время, чтобы понять их целиком. Таким образом, предсказуемость - это не видение полной законченной картины, а скорее понимание структуры определенного фрагмента и возможность быстро понять, куда он встраивается. На самом деле, специфика хорошей кодовой базы такова, что ее можно понять по частям, и она не должна требовать от разработчиков необходимости думать обо всем сразу.
Миграция платежной системы в облако: Зачем и стоит ли?
Привет! Наша компания занимается разработкой платформы для процессинга электронных платежей. Платформа предоставляется в аренду по White-label модели другим компаниям, которые хотят начать бизнес в области процессинга электронных платежей, при этом получив ряд “плюшек”:
- быстрый запуск;
- готовая PCI DSS ready инфраструктура;
- дополнительная поддержка, в том числе при прохождении аудита PCI DSS;
- брендирование;
- гибкая цена.
В данной статье мы хотели бы поделиться своим опытом перехода на облачную микросервисную архитектуру, обозначить с практической точки зрения плюсы такого подхода. Материал в равной степени будет интересен как начинающим специалистам DevOps, которые хотят получить базовые представления о построении комплексных самостоятельных облачных систем, так и техническим специалистам финтех компаний, которые столкнулись с ограничениями архитектуры своих существующих решений.
Будучи одними из первопроходцев на рынке решений для процессинга электронных платежей, мы построили архитектуру платформу на базе популярных на тот момент (примерно 2012 год) и хорошо зарекомендовавших себя решений - PCI DSS ready инфраструктура с аппаратными межсетевыми экранами Cisco ASA, с сегментацией сети, использовались отдельные хосты для каждой роли - фронтенд с админкой, платежными формами, API и incoming/outgoing прокси; процессинг; хосты выдачи вакантных ключей для шифрования карточных данных; хосты с реляционными БД и т.д. Стек был тоже достаточно традиционный - PHP, Apache, MySQL.
Эта статья — перевод оригинальной статьи Andy Li из Vue Mastery "Vue 3 Migration Build: safely upgrade your app to Vue 3 (Pt. 1)".
Команда Vue недавно выпустила долгожданный билд миграции для Vue 3. Если вы думали об обновлении своего приложения с Vue 2 до Vue 3, это то, что вам нужно.
Процесс обновления приложения до последней версии фреймворка может оказаться непростой задачей. Эта серия статей создана, чтобы упростить этот процесс.
Vuex — это потрясающая библиотека управления состояниями. Она проста и хорошо интегрируется с Vue. Зачем кому-то уходить от Vuex? Причина может быть в том, что предстоящий релиз Vue 3 раскроет заложенную в ее основе систему реактивности и предложит новые способы структурирования приложения. Новая система реактивности настолько мощная, что это можно использовать для централизованного управления состояниями.
. . .
Нужно ли вам общее состояние?
Бывают обстоятельства, когда обмен данными между несколькими компонентами становится настолько сложным, что вам необходимо централизованное управление состоянием. К таким обстоятельствам относятся:
Наверно все работали с формами и понимают как это сложно. В свое время я смотрел разные решения и одним из лучших был Vuetify. Сейчас решений стало больше, но все они однотипны (я не буду брать во внимание форм генераторы). В чем то это связано с ограничением самого Vue и его философией. Но для меня все таки странно, что время идет, а прогресса нет. Странно что люди вокруг пытаются меня убедить что это нормально.
Я попытаюсь рассказать о ключевых ошибках при работе с формами и дам рекомендации как их не допустить. Также рассмотрим идеально не идеальный пример работы с формой. А выводы каждый сделает сам.
