Посты

Сортировать дате ↓ комментариям

  • Материалы для обсуждения на пятый технический коммитет

    Мы подготовили для вас Напоминаю ссылки на ЧТЗ

    Технический комитет

  • Материалы для обсуждения на четвертый технический коммитет

    Коллеги, добрый день.

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

    Ниже ссылки на документы, которые хотелось бы обсудить, и при согласии принять (либо принять с замечаниями) на следующем техническом комитете. В рамках этих документов хотелось бы чтобы вы смотрели на технические аспекты этих документов, а не на политические. При этом любые замечания приветствуются

    1) Обсуждение ЧТЗ для вуза-поставщика (основателя) https://docs.google.com/document/d/1RjBn1bWIDwiFZU...

    2) Обсуждение ЧТЗ для вуза партнера (потребителя) https://docs.google.com/document/d/18m7qknEYspzBb-...

    3) Оно реализовано в соответствии с техническому порядку работы с вузами-патнерами (https://docs.google.com/document/d/1_hi5xZyrSIuDTs...) - его тоже можно обсуждать

    4) Кроме того в контексте текущей ситуации хотелось бы получить обратную связь на "Декларацию об открытости технологической платформы НПОО", которая может стать хорошим инструментом внешнего позиционирования https://docs.google.com/document/d/1u_YDme-1yLJ6sr...

    5) Порядок проведения приемочных испытаний - Юрий Куприянов внесет свои предложения на эту тему


    Комментарии можно оставить в тексте в режиме комментирования - либо оставить в виде комментариев к этому посту, указав номер обсуждаемого документа.


    Технический комитет

  • Подробности по обновлению платформы от 4 декабря 2015 года

    4 декабря 2015 было проведено обновление основных подсистем. В это обновление вошло большое количество улучшений и доработок, которые были сделаны с октября месяца. Более подробнее об обновлениях:

    Модуль SSO (итого 41 задача). Стоит отметить следующие:

    1. Обновили логику заведения новых пользователей, сделав ее более простой и понятной
    2. Фамилия и Имя теперьобязательные поля для пользователя при логине и прохождения курсов (важно для прокторинга - передается как параметры + подготавливаем пользователей к получению сертификатов)
    3. Реализовано отображение картинки на странице профиля
    4. Реализован вход зарегистрированных пользователей через логин или email (раньше только логин и пользователи путались)
    5. Формы регистрации поправлены для корректного отображения под мобильными устройствами
    6. Реализовано сохранение utm-меток в таблице пользователей (для дальнейшего анализа результативности маркетинговых компаний)
    7. Исправления многих мелких ошибок (навигация, формат ссылки в в письме регистрации, пр.)

    Модуль PLP (итого 86 задач). Стоит отметить следующие:

    1. Реализована оплата курсов на базе провайдера Yandex-касса (можно оплатить картой и Yandex
    2. Реализована отписка от курса - можно отписаться от любого курса, кроме случая, когда пользователь оплатил или был записан в рамках платной массовой записи на курс и случая, когда пользователь записан в рамках бесплатной массовой записи, где выставлен соответствующий флаг - "Студенты не могут самостоятельно покидать курс"
    3. Реализована массовая запись на курс в платном и бесплатном режиме, с возможность запрета самостоятельного отчисления студентов с курсов.
    4. Решена проблема с отсутствующими картинками
    5. Доработано отображение "Случайного курса"
    6. Доработки по созданию и отображению статических страниц с информацией на платформе
    7. Повышено удобство работы с административной панелью администратора, для ускорения работы службы поддержки
    8. Добавлено отображение страниц преподавателей. Со стороны службы поддержки будет сделан запрос на размещение информации о них.
    9. Исправлено много мелких ошибок и замечаний

    Модуль EDX. Компоненты были обновлены в рамках подготовки к запуску прокторинга.

    Технический комитет

  • Требования к прокторингу по состояние на 05.11.2015

    Коллеги, в процессе реализации и взаимодействия с коллегами из других вузов требования к прокторингу у нас меняются пока еще. Однако на данный момент их можно зафиксировать в следующем виде https://docs.google.com/document/d/1AgMhI_XTlDsqMxbI2_NAi4kYsHAE1Y1Z6ec0ezxl3_s/edit

    Технический комитет

  • Пожелания по улучшению функциональности к обсуждению второго технического комитета от 05.11.2015

    Предложения по улучшению функциональности и комментарии по ним собраны в https://docs.google.com/spreadsheets/d/1C51hCbsIOmyS8eKWC2-E0Uui0h_9gqT0UfRsr_v7BFw/edit#gid=0. Предлагается пройтись по ним и вынести на быстрое голосование каждое из них, выслушав позицию вуза и пояснив в чем суть изменений.

    Технический комитет

  • О порядке учета, отслеживания и реализации обращений вузов по доработке функциональности системы

    Коллеги, на первом этапе предлагается коммуникацию выстраивать по отслеживанию "пожеланий" к системе, которые возникают в процессе работы с помощью следующей таблички, которую мы к четвергу дозаполним окончательно и дальше будем поддерживать актуальной https://docs.google.com/spreadsheets/d/1C51hCbsIOm...

    Туда попадут все "хотелки" от вузов, которые стекаются к нам по всем информационным каналам.

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

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

    Технический комитет

  • Частное техническое задание на систему приема оплаты

    Коллеги, добрый день.

    Хотелось бы предложить вашему вниманию первую версию частного технического задания на систему оплаты. Она доступна по ссылке https://docs.google.com/document/d/1XyzYARiGcev6Mc... в режиме сбора комментариев и при этом используется как базовая в реализации текущего функционала платежной системы.

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

    Формально, должны предлагаться следующие варинаты развития событий:

    1. утвердить
    2. утвердить с указанными комментариями(комментарии первоначально указать в гуглдоке, и сослаться на пункты в которые они внесены)
    3. отправить на доработку с последующим выносом на повторное обсуждение (с обоснованием причин и замечаниями)
    Собственно в комментарии к посту хотелось бы увидеть ваши предложения по документу, с указанием вуза мнение которого вы высказываете

    Технический комитет

  • Вопросы для рассмотрения архитектурного комитета от 19.02.2015

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

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

    Пожалуйста, в начале комментария указывайте имя вуза, который вы официально представляете.

    Коллеги, крайне важно получить ваши ответы как можно быстрее - в качестве крайнего срока предлагаю до 10-00 22.10.2015

    1.Хостинг серверов для специальных заданий в рамках отдельных курсов

    Описание: для отдельных курсов может требоваться специальным образом настроенные сервера для размещения веб-приложений, используемых в курсе; либо - хостинг определенного технологического стека (например, в настоящий момент есть запрос на хостинг сервера на стеке Microsoft IIS, в составе: IIS не ниже 7 версии, .Net 4.5, ASP.NET, MVC 4, MS SQL Server 2012).

    Вопрос: Осуществляется ли предоставление и администрирование хостинга для специальных типов интерактивных задач силами Ассоциации, либо вопрос хостинга для своих курсов каждый вуз решает самостоятельно, а Ассоциация только формулирует требования по нагрузке и уровню сервиса для таких серверов?

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

    2.Модель покупок на Платформе

    Описание: Покупка платного трека прохождения курса на Платформе может быть организована двумя различными способами: как покупка товара (осуществляется оплата каждого курса, общего счета клиента нет), либо как внутренний счет клиента (по аналогии со счетом оператора сотовой связи - клиент сначала пополняет счет, а потом расходует деньги с него на оплату курсов и другие услуги).

    Вопрос: Выбор модели

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

    3.Базовая технологическая схема определения принадлежности студента к вузу

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

    Вопрос: Каким образом обеспечивать идентификацию принадлежности студента к определенному вузу-потребителю?

    Варианты решений:

    1) В профиле пользователя вводится обязательное поле "Вуз". Преимущества решения: не требует от вузов организации сервиса на своей стороне. Недостатки:

    • поле неоднозначно - релевантно и для актуального студента, и для выпускника;
    • поле должно быть обязательным, но по доменной модели таковым не является: у пользователя может не быть принадлежности к определенному вузу;
    • невозможно автоматически отличить актуального студента от пользователя, просто указавшего вуз в этом поле и не являющегося студентом;
    • невозможно в будущем автоматически связывать данные студента в системах вуза и на Платформе (нет уникального идентификатора, общего для обеих систем).

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

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

    Недостатки:высокие накладные расходы на поддержание информации актуальноей. Задержка между регистрацией студента и получение им статуса "проведенный студент вуза Х"

    3) Вуз-потребитель предоставляет сервис идентификации по протоколу OAuth 2.0 на своей стороне; студентами вуза считаются только пользователи, входящие на Платформу через идентификатор вуза, либо осуществившие привязку своего аккаунта к вузу (по аналогии с социальными сетями). Минимальное типовое решение может быть создано технической командой платформой и предложено вузам для разворачивания у себя.

    Преимущества: решение снимает недостатки предыдущих решений. Недостатки: требуются работы по внедрению со стороны вуза-потребителя; требуетя разработка специальных решений для вузов потребителей; не у каждого вуза может быть централизованная база студентов и идентификационными данными.

    4.Выбор сервиса интернет-эквайринга или сервиса приема платежей

    Описание: Для обеспечения приема оплаты у физических лиц в рамках Платформы требуется выбор и подключение сервиса приема платежей (примеры: Robokassa, Platron и т.д.) либо сервиса интернет-эквайринга.

    Вопрос: Запрос опыта использования платежных систем и интернет-эквайринга у членов комитета и экспертов, особенности, критерии выбора.

    Предварительные предложения по платежным системам:

    Сервис

    Преимущества

    Недостатки

    Примечание

    Robokassa




    Яндекс.Касса




    Visa QIWI Wallet




    Интернет-эквайринг Газпромбанк




    RBK Money




    Platron




    PayAnyWay




    ?Ваш вариант?




    5.Подключение CDN для файлов-материалов курса

    Описание: В случае размещения в качестве материалов курса файлов большого объема (начиная с десятков Мб) стоит рассмотреть вариант хранения и раздачи файлов с CDN, а не из штатного хранилища edX (Mongo).

    Преимущества: снижение трафика с основного хранилища, ускорение загрузки клиенту, возможность организации хранения файлов по папкам, использования интерактивных внутрибраузерных приложений (напр. WebGL).

    Недостатки: использование нештатных средств при загрузке и размещении ссылок на файлы на страницах курса (не выбор файла из загруженных, а добавление внешней ссылки).

    6.Выбор базового CDN провайдера

    Описание: Подсистема хранения видео осуществляет конечную раздачу контента студентам используя ресурсы CDN сетей. В рамках работы портала у нас был опыт работы с двумя такими системами CDNVideo и NGenix. Мы начали работать с CDNVideo и опыт использования показал, что у нескольких процентов пользователей регулярно возникали трудновоспроизводимые проблемы с просмотром видео, которые по нашему мнению были связаны с особенностями организацией кеширования у данного CDN провайдера. Данные проблемы вызывали нарекания у пользователей, увеличивая нагрузку на службу поддержки.

    После перехода на NGenix проблемы прекратились, видеоподсистема работает в штатном режиме.

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

    Вопрос: Выбор CDN провайдера

    Предложенное решение: Предлагается использовать провайдер NGenix в качестве базового.

    Вопросы для рассмотрения архитектурного комитета

    На 15.10.2015

    Актуальные вопросы для экспертного решения по архитектуре и функциональности Платформы:

    Технический комитет