Http://jscouse.com закрыт, зато http://a.jscouse.com открывается

Meta
1

Привет.

Я буду периодически делиться соображениями о том как разрабатываю jscourse.com. Соображения будут разного плана: от выбора шрифта и отступов в тексте до описания процесса деплоя. Писать код в одиночестве и не обсуждать результаты и не слышать альтернативное мнение - скучно. Кому-то мой опыт и мнение может быть полезным, а мне будет интересно ответить на вопросы и поучаствовать в дискуссии.

Года 3 назад я написал на meteorjs первую версию jscourse.com. Сегодня я закрываю ее. И открываю новую версию https://a.jscourse.com. a означает альфа: функционал и содержание будет меняться. Все задания и статьи с предыдущей версии сохранены и перенесены. Отзывы (которые я так ценю) сохранены, но пока не вывешены.

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

Проблема с индексированием поисковиками метеор приложений (потому что все метеор приложения SPA по определению). Решение есть этому вопросу, но оно костыльное, и не понятно на сколько снижается качество индексирования.

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

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

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

В новой версии я отказался от админки (данные храню в файлах, аккаунты пока не заводил), добавил локализацию, деплой с помощью pm2, и деплою данные сразу с кодом. Такой подход к деплою дает гибкость откатиться на предыдущую версию, плюс некоторую экономию денег: проект можно разместить на VPS вместе с пачкой других проектов.

На сегодня все. Последующие посты буду писать тут же в meta. Буду рад твоим комментариям и вопросам.

5 лайков
2

Добра в карму, молодец что делаешь.

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

3

Хороший вопрос.

Не жалею. Если бы я не выбрал метеор, я бы не смог быстро убедиться в работоспособности идеи. В сумме метеор сыграл положительную роль в это истории. Он избавил от необходимости принимать решения на самых ранних стадиях проекта.

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

Я и сегодня буду рекомендовать метеор для некоторого класса задач. Особенно тем, кто хочет запилить идею в одиночку полностью на javascript или показывать real-time данные.

4
  1. Это PET проект для души?
  2. Платформа остается на Meteor?
  3. Код не будет открыт на GitHub для совместной работы?
5

Хорошие вопросы

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

  2. От метеора я полностью отказался. Платформа представляет набор проверенных временем пакетов (expressjs, handlebars, react, mobx) которые я пытался максимально не связывать друг с другом. Например не использую клиентского раутера или ssr чтобы избежать жёсткой связки раутера и клиентского фреймворка.

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

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

6

Очень круто что проект будет и дальше жить.
Как ты видишь конечный\промежуточный результат своей работы?

Это будет SPA или server-side rendering на nodejs?

7

Конца проекту нет. Отсюда следюут некоторые техниечские решения: готовлю проект к долгой жизни.

Вижу три взаимонеисключающих направлений развития.

Первое направление - сам контент. Задачи, статьи, опросники, видео, примеры, курсы. Как видно из текущего сайта, реализованы только статьи и задачи. Они не останутся в виде кучи контента без какой либо связи. Новый тип взаимодействия “курс” свяжет их между собой.

Второй - способ представления контента. Порядок не отражает приоритетов.

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

Третий - удобство. Тут тоже куча идей. От банальных аккаунтов чтобы сохранять в них прогресс, до автоматических напоминаний что пользователь не проделал прогресса за последние 3 дня, например.

Ближайшие цели - выпустить законченный курс основ JS. Для этого понадобится:

  • новый тип страницы - опросник
  • новый тип страницы - курс
  • статьи, задачи, опросники по темам курса
  • дополнительные материалы

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

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

Я выше писал что отказался от метеора. Я рассматривал вариант писать SPA приложение. Отказался от этой идеи. Разработка SPA означает что мне понадобится реализовывать способ доставки данных клиенту (ajax или websocket), API (продумать нужно ли закладывать возможность открытия API), продумывать протокол, описывать обработку ошибок, решать проблему клиентского раутинга и серверного рендеринга для корректного индексирования. Куча действий ради не понятно чего. Как вариант - взять готовый фреймверк. Гарантий что он будет существовать через 3 года - ровно ноль. Пакет можно заменить или написать самому, а фреймверк не заменишь, ибо он “впаян” в часть реализации.

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

Поэтому сейчас приложение выглядит так:

  • на сервере рендерятся handlebars в html. Данные, которые нужны компонентам вставляются прямо в тело страницы.
  • на клиенте инициализируются независимые компоненты. Сегодня это чистый js и реакт.
  • раутинг чисто серверный.
1 лайк
8

звучит очень здраво!

соглашусь, SPA здесь излишне.

данные в JSON-е просто или markdown? (интересный пример - реализация learn.javascript.ru)

Надеюсь что все получиться!

Курс будет асинхронным или присутствие преподавателя никто не отменял?

9

В JSON очень неудобно редактировать текст с кавычками, которого будет много в проекте. Плюс неудобно читать/писать многострочные данные, поддерживать форматирование отступами.

Использую YAML + Markdow. С собственным привкусом. Это большая и неоднозначная тема, которую я подниму в будущем. Если присмотреться, то я в самом YAML файле использую значения из этого же файла (смотри {{fn}} и {{> solution}}. А так же описываю метаинформацию в комментарии в коде в YAML.

Для примера данные от Проверить каждый элемент массива на удовлетворение условию лежат в файле jscourse.com/data/challenge/contains.yml выглядят так (это только часть).

fn: contains
solution: |
  function {{fn}}(where, what) {
    if (!what.length) {
      return true
    } else {
      return what.every((item) => {
        return where.indexOf(item) !== -1
      })
    }
  }
ru.title: Проверить является ли один массив подмножеством второго
ru.description: |
  Реализуй функцию `{{fn}}(where, what)`. Если все элементы массива `what` содержатся в массиве `where`, функция должна возвращать `true`.
  Пустой массив является подмножеством любого массива. Порядок вхождения элементов в массив не имеет значения. Примеры:
  ```
  /***
  jsEval: true
  evalBefore: |
      {{> solution}}
  */
  {{fn}}([1,2,3], [3,2])
  ```

Я смотрел как описаны данные на javascript.ru вот тут: GitHub - javascript-tutorial/en.javascript.info: Modern JavaScript Tutorial. Мне нужна гибкость другого рода чем то, что выбрал Илья для своего проекта.

То что он разнес по разным файлам, я разместил в одном. Где он выбрал иерархическую структуру, я взял плоский вариант. Иерархию я буду создавать с помощью отношений ресурсов, описанных плоско (считай в массивах).

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

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

10

Ух ты круто!!! Я думала все уже давно забыто, а оказывается продолжение следует))

11

На просторах интернета встречал много интересных задач (вроде https://checkio.org/, https://www.codewars.com/ и т.п.). Имеет ли смысл их локализовать и внедрять здесь на этом проекте? По большому счету отличие будет только в локализации, но это тоже немаловажный момент. У меня есть джуны, у которых вообще туго с английским, но JS они учат и понемногу, но верно продвигаются вперед. Говорят, что этот сайт им очень помогает.

Еще один был комментарий: стало очень пугающе непонятно выглядеть страница с заданием в секции проверки кода. Раньше там не было тестов и все выглядело просто. Теперь все стало намного удобнее (просто они пока еще этого не понимают), но чуть более запутано для новичков. Возможно стоит создать страничку, на которой человек познакомиться с процессом получения/проверки задачи, что такое тесты, редактор кода и т.п.

PS Могу помочь с некоторыми задачами. Возможно стоит сделать доску на Trello для организационных моментов развития проекта и чат в Slack?

12

Да. Я тоже видел много ресурсов с заданиями. Большинство этих задач реализуемы в рамках созданной системы. Я однозначно буду переносить задачи с этих ресурсов на jscourse.

Я очень рад слышать как моя работа влияет на них.

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

Дизайнеры, с которыми я общался, говорили что существующий вид редактора решения будет непонятен начинающим:

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

При всех этих минусах, я вижу технические плюсы

  • ученик знакомится с понятие тестов
  • ученик учится понимать чужой код
  • за счет интерактивного цикл “теория” → “проверка” → “анализ результата” ускоряется. Таким образом упрощает ученику изучение системы так, как он бы делал реальным кодом (через console.log).

То о чем ты говоришь - страничка с объяснениями как пользоваться системой - отличное решение. Я планирую записать видео где расскажу и покажу как пользоваться сайтом. И это видео будет обязательной частью каждого курса. Единственное что я не планирую записывать это видео сейчас. Я сделаю это прямо перед готовностью первого курса, когда формат взаимодействия пользователя и сайта будет устаканен.

13

Слак и трелло считаю оверкилом. Я придумаю как настроить взаимодействие а так же как подписывать задачи, которые законтрибьючены обществом. Работа должна быть подписана автором. Напишу о выводах до понедельника в личку.

14

"Я наберу группу, с которой мы пройдем этот курс, соберу фидбек от ребят, посмотрю какие вещи работают, какие нет, "
А как можно попасть в эту группу ?

15

Информация будет в анонсе. Анонс на форуме. Набор группы не откроется в ближайшие 2-4 месяца.