• Angular — настройка среды разработки и production сборки с AOT-компиляцией и tree-shaking (Gulp, Rollup, SystemJS)

    • Tutorial

    Одна из особенностей Angular, присущая и первой и новой версии — высокий порог вхождения. Новый Angular, помимо всего прочего, трудно даже запустить. А и запустив, легко получить 1-2 Мб скриптов и порядка нескольких сотен запросов при загрузке hello world страницы. Можно, конечно, использовать всякие стартеры, seed'ы или Angular CLI, но для использования в серъезном проекте нужно самому во всем разбираться.


    В этой статье я постараюсь описать, как настроить удобную среду разработки с использованием SystemJS, и production сборку Angular приложения на основе Rollup, с выходом около 100кб скриптов и нескольких запросов при открытии страницы. Использовать будем TypeScript и SCSS.


    Попробовать все в деле можно в моем angular-gulp-starter проекте.


    Читать дальше →
  • Битва экстрасенсов в технической поддержке, или как помочь пользователю правильно проставить приоритет инцидента

      Пользователь Василий обращается в техподдержку «Не выделяется номер при регистрации документа ошибка 1234, для исправления приходится перезапускать службу сервера приложений. Ошибка возникла 05.05 приблизительно в 15:10-15:50. Воздействие инцидента: Снижена эффективность работы пользователей».

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


      Читать дальше →
    • Темная сторона TypeScript — @декораторы на примерах

        Декораторы — это невероятно круто. Они позволяют описывать мета информацию прямо в объявлении класса, группируя все в одном месте и избегая дублирования. Ужасно удобно. Однажды попробовав, вы уже никогда не согласитесь писать по-старому.


        Однако, несмотря на всю полезность, декораторы в TypeScript (заявлены также на стандарт) не так просты, как хотелось бы. Работа с ними требует навыков джедая, так как необходимо разбираться в объектной модели JavaScript (ну, вы поняли, о чем я), API несколько запутанный и, к тому же, еще не стабильный. В этой статье я немного расскажу об устройстве декораторов и покажу несколько конкретных приемов, как поставить эту темную силу на благо front-end разработки.


        Помимо TypeScript, декораторы доступны в Babel. В этой статье рассматривается только реализация в TypeScript.


        Читать дальше →
      • Верстка: отображаем пользовательский контент

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


          Читать дальше →
        • Приложения в системе электронного документооборота. Часть 5: Задания и маршрутизация документов в приложениях СЭД

            Работа с заданиями — это, пожалуй, наиболее часто используемая функция системы электронного документооборота. Казалось бы, что может быть проще — доставить документ исполнителю и получить реакцию на его обработку, но практика показывает, что задание — один из самых сложных объектов в СЭД. Российские СЭД имеют мощные средства управления заданиями. Расскажем, как реализованы задания в Docsvision, и какие есть особенности их реализации.
            Читать дальше →
          • Актуальность модели PaaS для систем электронного документооборота

              Про модель «СЭД в формате SaaS» сказано уже достаточно много. Напомним, примерно с 2010 года на российском рынке стали появляться игроки, создающие новые продукты и решения в таком формате. Они задали тренд. К 2011-2012 году на рынок вышли несколько крупных игроков с SaaS-решениями по проектному управлению, которые, в том числе, включали в себя элементы финансовых систем, CRM и системы электронного документооборота. Эти решения напрямую не являются СЭД в формате SaaS, но при этом частично решают задачи современных СЭД и даже позволяют в том или ином виде автоматизировать уникальные бизнес-процессы компании.
              Читать дальше →
            • Приложения в системе электронного документооборота. Часть 4: Конструктор бизнес-процессов

              Вторым важнейшим компонентом приложения СЭД, помимо документов или карточек документов (в модели приложения, реализованной в платформе Docsvision), являются процессы. Если машина состояний, контекстно-ролевая модель и скрипты определяют поведение и логику отдельного документа в системе, то бизнес-процессы предназначены для реализации сложных сценариев маршрутизации, взаимодействия с внешними по отношению к СЭД приложениями, для обработки событий, не связанных с активностью пользователей, и другой серверной активности в отношении документов.
              Читать дальше →
              • –1
              • 3,1k
              • 3
            • Прототипы как предчувствие продукта

                Представьте себе: ваш ребенок умирает от редкой и неизлечимой болезни. Его бьют посторонние люди, и он страдает от жуткой боли. В самом конце он усыхает до размера кошки, становится совсем серым и, наконец, умирает. А потом случается хеппи-энд: вы узнаете, что в роддоме произошла ошибка… Ф-ф-фу, напугал, дур-рак!

                Поздравляю, вы познакомились с жизненным циклом прототипа обыкновенного.

                Привет, друзья! Прототипы — это становой хребет продуктового дизайна. Я расскажу, почему мы в команде используем только hi-fi прототипы и отказались от всех прочих.

                Ранее мы уже говорили про структуру приложений и определение принципов навигации. Кул. Но что со всем этим делать дальше? Не вопрос! Конечно, нужно разработать прототип. Прототип нужен для раннего тестирования MVP, для снижения рисков проектирования, для проверки пригодности предлагаемых решений, для показа акционерам, для краудфандинга и для экономии времени при общении с разработчиками. Отовсюду мы слышим стоны. Всем нужен прототип. Мы должны протянуть руку помощи, и мы ее протянем.
                И тут у меня для вас 2 новости. Сначала хорошая: плохая новость могла бы быть намного хуже…

                10 min read
              • Теория ограничений в интерфейсах (кто убил старого графа?)

                  Привет, меня зовут Александр Волков, я проектирую интерфейсы в компании Docsvision. Цель этой статьи — помощь разработчикам сложных программных продуктов. Ключевое слово — сложных. Спроектировать сайт-визитку сегодня может даже пятиклассник прямо на своем смартфоне, и при желании можно скачать зип-архив с готовым шаблоном блога или корпоративного сайта. Однако если ваше приложение посложнее обычного интернет-магазина, то, вполне вероятно, строить структуру и определять принципы навигации вам придется самостоятельно, наступая на разбросанные повсюду грабли. Здесь может пригодиться наш опыт. Я опишу один из возможных способов проектирования интерфейсов, который успешно опробован в нашей компании. Это делается легко и просто (практически в полуавтоматическом режиме) при помощи программы FlyingLogic.
                  Читать дальше →
                • Приложения в СЭД. Часть 3: Контекстно-ролевая модель документа, права и оптимальный интерфейс для работы с документами

                  Важное отличие приложений СЭД от других привычных пользователю приложений (например, ERP-систем) в том, что документ СЭД – это объект с очень сложным и длительным жизненным циклом. Например, документ вида Договор — разрабатывается, согласовывается, утверждается, передается контрагентам, по нему ведется активная работа, к нему накапливаются приложения, создаются дополнительные артефакты, он архивируется, списывается и пр. Естественно, логика его обработки и права доступа к данным документа зависят от этапа его обработки. Но это еще не самое сложное.
                  Читать дальше →
                Самое читаемое