Каждый год, начиная с 2011 года, Stack Overflow проводит опрос, в котором более 100 000 разработчиков задают вопросы об их работе, карьере и привычках программиста. Особенно выделяется один из этих выводов: 86,7 % разработчиков выучили новый язык, фреймворк или инструмент без помощи какого-либо формального обучения. Об этом свидетельствует обилие ресурсов для обучения кодированию, разбросанных по всем средам, которые позволяют заниматься самообучением. Это варьируется от Reddit, Udemy, Khan Academy, YouTube, Coursera, EdX и т. д. Затем у вас есть ресурсы, предназначенные исключительно для обучения программированию, такие как CodeAcademy, FreeCodeCamp, The Odin Project, и этот список можно продолжить. Однако объем выбора представляет собой проблему: как выбрать правильный ресурс среди такого множества?
Что такое Девлаб?
DevLab по своей сути представляет собой библиотеку объединенных ресурсов, которая поступает из любого онлайн-формата, а затем оценивается сообществом преданных своему делу разработчиков. Каждый из этих ресурсов классифицируется по определенной концепции, такой как изучение ES6, CSS или полные пути того, как начать свое путешествие. Каждая концепция может быть сохранена в вашей личной библиотеке, которая использует базу данных SQL для записи того, сколько раз этот источник был сохранен. Выбирая определенный ресурс для сохранения, вы проводите голосование, чтобы помочь другим найти самый популярный материал. В своей личной библиотеке вы можете фильтровать темы по категориям, а также сортировать элементы по популярности и недавно добавленным ресурсам.
Используемые технологии
Этот проект был создан с использованием jQuery и UIkit для внешнего интерфейса, а для внутреннего интерфейса использовались NodeJS, Express, MySQL и Passport. Другие технологии включали MomentJS, Sequelize (ORM для MySQL), BideoJS и Bcrypt, все из которых были развернуты на Heroku. Некоторые из самых больших проблем в этом проекте связаны с получением информации, которую мы хотели, в правильном формате для правильного отображения и аутентификацией пользователя.
Полный код доступен на GitHub (https://github.com/sajeelmalik/Dev-Lab). В этой статье я буду комментировать свой личный вклад в проект.
Выполнение
Для DevLab мы выбрали одну страницу, на которой весь наш контент генерируется динамически с помощью небольшого HTML-скелета. Я начал с определения базовой маршрутизации, которая нам потребуется для чтения и обновления информации о нашем API, и создал стандартный сайт, который использовал образцы объектов для заполнения данных. Эти образцы позже использовались в качестве схемы для нашей базы данных. Изучение создания доступной таблицы соединений между пользователями и контентом и заполнения базы данных с помощью Sequelize потребовало немало проб и ошибок, но в конце концов мы добились того, чтобы это работало.
Проблемы с синтаксисом и структурой
В таблице соединений записано, какие пользователи сохранили какой контент, который затем будет заполняться пользовательской библиотекой на основе их уникального идентификатора пользователя. Таблица соединения позволила нам запросить в пользовательской базе данных полную информацию о каждой части контента, поскольку она была сохранена как вложенный объект внутри пользовательского объекта. Хотя Sequelize был удобен тем, что позволял нам сортировать результаты, которые были прямыми ключами пользовательского объекта, эти объекты контента хранились в массиве несуществующей таблицы (поскольку источником данных была таблица соединений). Это привело к проблеме, потому что мы не могли напрямую запрашивать таблицу соединения и не могли заставить Sequelize сортировать вложенный массив. Прежде чем это осознать, я создал функцию, которая будет генерировать весь пользовательский контент, думая, что нам придется сделать несколько разных вызовов Sequelize. На самом деле решение пришло от UIkit, когда один из моих товарищей по команде понял, что UIkit имеет встроенную функцию сортировки, и все, что нам нужно было сделать, это записать некоторые данные контента в его атрибут данных по мере его создания.
Чтобы создать фильтр категории, мы должны пройти по выбранной категории, отфильтровать массив пользовательского контента и вернуть массив соответствующего контента. Поскольку на тот момент функция пользовательской библиотеки была постоянным приспособлением, мне пришлось преобразовать массив в объект, который соответствовал бы требованиям функции.
Вывод
В целом, мы были очень довольны конечным продуктом. Мы добились почти всего, что планировали. Первоначально хотел, чтобы обзоры/комментарии были функцией и разделом, содержащим фактические примеры кода, но в итоге сократили их, чтобы уложиться в 5-дневный график этого проекта. Что касается будущего направления, такой проект мог бы значительно выиграть от наличия фильтра, который алгоритмически присваивает контенту рейтинг популярности/времени. Поскольку веб-разработка движется так быстро, важно, чтобы пользователи знали, насколько давно стали популярны статьи. Будущие версии также позволят пользователям редактировать отправленный ими контент и создавать свои собственные рабочие процессы, выбирая контент и позволяя пользователям просматривать эти рабочие процессы.
Источник: