Содержание
ВВЕДЕНИЕ
2 Анализ требований
2.1 Основания для разработки
2.2 Назначение разработки
2.3 Требования к программе
3 Проектирование
3.1 Выбор методологии проектирования разработки ПО
3.1.1 «V-Model»
3.1.2 «IncrementalModel» (инкрементная модель)
3.1.3 «RAD Model» (rapid application development model илибыстраяразработкаприложений)
3.1.4 «AgileModel» (гибкая методология разработки)
3.1.5 «SpiralModel» (спиральная модель)
3.2 Функциональная модель
3.3 Структура ПО
3.4 Проектирование БД
3.5 Проектирование интерфейса пользователя
5 Тестирование
ЗАКЛЮЧЕНИЕ
Сокращения, обозначения, термины и определения
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
Приложение А Создание источников данных
Приложение Б Создание учетной записи пользователя
Приложение В Лог загруженных данных
Приложение Г Пользовательский интерфейс приложения
ВВЕДЕНИЕ
Актуальность создания данного сервиса состоит в том, что в настоящее время социальные сети активно развиваются, люди в социальных сетях активно размещают различного рода информацию. Программа «4head» исправить одну из главных проблем этого источника данных — плохо систематизированную информацию.
Программа «4head» носит инновационный характер в социальной сфере, направлена на группировку информации социальных сетей для дальнейшего предоставления ее конечному пользователю вне зависимости от типа контента.
Предметом исследования данной работы выступают социальные сети, и способы агрегации их, и создание WEB приложения которое будет автоматически собирать контент из социальных систем, группировать его по пользователям которые создали этот контент, по показателю интереса к загружаемому контенту и тегам.
Целью проекта является формирование теоретических знаний по созданию программного обеспечения и практических навыков по его разработке.
В поисках решения данной задачи в работе проводится разработка программного обеспечения под названием «4head».
Для выполнения дипломного проекта были поставлены следующие задачи:
• Изучение предметной области
• Составить назначение для разработки
• Изучение требований к программе
• Выбор инструментов разработки
• Спроектировать БД и интерфейс пользователя
• Разработать сервис
2 Анализ требований
2.1 Основания для разработки
В настоящее время социальные сети являются источником огромного количество различных данных, от новостей и аналитических сводок до развлекательного контента, данные публикуются как пользователями, так и специальными тематическими группами.
Эта информация не как не систематизирована и пользователю с конкретными интересами порой невозможно отфильтровать или отсортировать данный контент по показателю интереса, проявляемого людьми к конкретной записи который, может говорить о её важности.
Исходя из этого существует необходимость в создании программы, которая могла бы загружать контент из социальных сетей автоматически и предоставлять его конечному пользователю в том виде, в котором ему требуется.
2.2 Назначение разработки
Открытый информационный сервис «4head» направлена на группировку информации социальных сетей для дальнейшего предоставления ее конечному пользователю вне зависимости от типа контента. Так же сервис «4head»
представляет собой не только агрегатор социальных сетей, но и социальную сеть как таковую предоставляя возможность размещать контент самому, который в последствии могут видеть и комментировать другие пользователи. Его функциями являются:
Предоставление публичного доступа к следующей информации:
• Просмотр открытых новостей
• Просмотр открытых комментариев
• Просмотр открытых изображений
• Просмотр тегов
• Просмотр информации о пользователе, который опубликовал тот или иной материал
2.3 Требования к программе
Исходя из оснований разработки, разрабатываемая система «4head» должна быть написана как приложение для браузера и доступна в сети интернет, а так иметь следующий функционал:
• Возможность авторизации и регистрации пользователя через различные социальные сети, а также по средством электронной почты.
• Добавления источника загружаемых данных, а именно добавление социальной сети и конкретного субъекта социальной сети из которого будет происходить получение информации.
• Автоматическая загрузка данных из добавленных субъектов социальных сетей по установленному расписанию
• Комментирование контента, ответа на комментарии
• Возможность добавления в избранное
• Предоставлять доступ к контенту в виде ленты
• Поиск информации по тегу, по социальной сети и по субъекту социальной сети
• Автоматически генерировать теги, для изображений
• Возможность подписки на субъект социальной сети что бы в последствии следить за новым контентом предоставляемым данным субъектом
• Визуальные уведомления пользователя о новом контенте по подпискам
3 Проектирование
3.1 Выбор методологии проектирования разработки ПО
В настоящее время имеется множество различных методологий для разработки ПО, если проанализировать их, то можно сделать вывод что самыми популярными моделями методология являются – водопадная и гибкая. Даже в последнее время гибкие методологии используются чаще в новых проектах. Важно понимать, что выбор методологии – очень важный момент в разработке продукта. Нужно учитывать особенности конкретного создаваемого продукта, всех участников и выбирать наиболее пригодную для проекта методологию.
Не существует универсального, подходящего всем проектам, набора условий для всех ситуаций при выборе той или иной методологии разработки ПО. В каждом конкретном случае нужно ориентироваться на специфику данного проекта.
Ниже мы рассмотрим самые популярные из методологий и сделаем выбор.
3.1.1 «V-Model»
V-модель – это улучшенная версия классической каскадной модели. Здесь на каждом этапе происходит контроль текущего процесса, для того чтобы убедится в возможности перехода на следующий уровень. В этой модели тестирование начинается еще со стадии написания требований, причем для каждого последующего этапа предусмотрен свой уровень тестового покрытия.
Для каждого уровня тестирования разрабатывается отдельный тест-план, то есть во время тестирования текущего уровня, мы также занимаемся разработкой стратегии тестирования следующего. Создавая тест-планы, мы также определяем ожидаемые результаты тестирования и указываем критерии входа и выхода для каждого этапа.
В V-модели каждому этапу проектирования и разработки системы соответствует отдельный уровень тестирования. Здесь процесс разработки представлен нисходящей последовательностью в левой части условной буквы V, а стадии тестирования – на ее правом ребре. Соответствие этапов разработки и тестирования показано горизонтальными линиями.
Рисунок 3.1 — V-Model
Когда использовать методологию?
• Если требуется тщательное тестирование продукта, то V-модель оправдает идею: validation andverification.
• Для малых и средних проектов, где требования ясны и фиксированы.
• В условиях наличия инженеров необходимой квалификации, особенно тестеров..
3.1.2 «IncrementalModel» (инкрементная модель)
Инкрементная модель — это метод, в котором проект проектируется, реализуется и тестируется инкрементно (то есть каждый раз с небольшими добавлениями) до самого окончания разработки. Это включает в себя как разработку, так и дальнейшую поддержку продукта. Он считается законченным в то время, когда удовлетворяет всем требованиям. Модель объединяет элементы каскадной модели с прототипированием.
Проект можно разложить на несколько составляющих, каждая из которых спроектирована и построена независимо от другой (билд). Каждый такой компонент поставляется клиенту по мере готовности, что позволяет сразу начать использовать продукт и избежать длительной разработки. Также это стимулирует большие инвестиционные затраты, но сокращает время ожидания результата. Модель помогает «сгладить углы», вместо того, чтобы выкатывать пользователю совершенно новую систему разом.
Есть и проблемы. Например, каждый новый билд должен быть интегрирован с предыдущим во всех системах. Разборка на билды тоже не элементарна. Если есть несколько билдов, которые еще и необходимо разобрать, все превращается в модель «Компилируй и исправляй ошибки». Как бы то ни было, большое количество сборок означает малое количество изменений между ними.
Рисунок 3.2 — IncrementalModel
Когда использовать методологию?
• Когда основные системные требования четко определены и понятны. В то же время некоторые части могут быть усовершенствованы с течением времени.
• Требуется ранний запуск продукта.
• Существует несколько рискованных функций или целей..
3.1.3 «RAD Model» (rapid application development model илибыстраяразработкаприложений)
RAD — методология, которая во главу угла ставит скорость и удобство разработки. Одно из главных условий — использование языка быстрой разработки. Это название абстрактного языка программирования, с помощью которого программист способен решать задачи быстрее, чем с представителями третьего поколения (C / C ++, Pascal или Fortran). RAD предполагает использование целого комплекса инструментов помимо языка быстрой разработки: системы сбора требований, среды разработки, фреймворки, программы для группового общения, ПО для тестирования.
Рисунок 3.3 — RAD Model
Когда использовать методологию?
• Может использоваться только при наличии высококвалифицированных и узкоспециализированных архитекторов. Бюджет проекта большой, чтобы оплатить этих специалистов вместе со стоимостью готовых инструментов автоматизированной сборки. RAD-модель может быть выбрана с уверенным знанием целевого бизнеса и необходимости срочного производства системы в течение 2-3 месяцев
3.1.4 «AgileModel» (гибкая методология разработки)
В «гибкой» методологии разработки после каждой итерации клиент может наблюдать результат и понимать, удовлетворяет ли он ему или нет. Это одно из преимуществ гибкой модели. Его недостатки включают тот факт, что из-за отсутствия конкретной формулировки результатов трудно оценить затраты на рабочую силу и затраты, необходимые для развития. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.
В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:
• отчёт о проделанной работе с момента последнего Scrum’a
• список задач, которые сотрудник должен выполнить до следующего собрания
• затруднения, возникшие в ходе работы.
Выбрав наиболее подходящую методологию, не стоит полностью следовать ей, зачастую некоторые методологии стоит дорабатывать под конкретный проект, и подстраивать под свой проект, можно что-то убрать или что-то добавить. К примеру, нормальной практикой считается парное программирование в водопадной методологии, если это будет полезно для проекта или для конкретной задачи, то почему бы и нет?
Рисунок 3.4 – AgileModel
Когда использовать методологию?
• Когда потребности пользователя постоянно меняются в динамическом бизнесе.
• Изменения на Agile реализуются за меньшую цену из-за частых инкрементов.
• В отличие от модели водопада в гибкой модели для запуска проекта достаточно лишь небольшого планирования.
3.1.5 «SpiralModel» (спиральная модель)
Спиральная модель представляет собой образец процесса разработки программного обеспечения, который объединяет идеи итеративных и каскадных моделей. Её суть в том, что весь процесс создания конечного продукта представлен в виде условной плоскости, разделенной на 4 сектора, каждая из которых представляет собой отдельные этапы ее развития: постановку целей, оценку риска, разработку и тестирование, планирование новой итерации.
В спиральной модели жизненный путь разрабатываемого продукта изображается как спираль, которая, начиная с этапа планирования, разматывается с прохождением каждого следующего шага. Таким образом, на выходе из из очередного витка мы должны получить готовый протестированный прототип, который дополняет существующий билд. Прототип, отвечающий всем требованиям — готов к выпуску.
Главная особенность спиральной модели – концентрация на возможных рисках. Для их оценки даже выделена соответствующая стадия.
Рисунок 3.5 –SpiralModel
Когда использовать методологию?
• Когда есть сложный и дорогой проект
• Когда каждый следующий шаг требует большого анализа для оценки последствий
Вывод
Рассмотрев наиболее популярные методологии разработки ПО, можно сделать выбор, что для нашего проекта отлично подойдет спиральная модель, т.к. в спиральной модели жизненный путь разрабатываемого продукта изображается как спираль, которая, начиная с этапа планирования, раскручивается с прохождением каждого следующего шага. Таким образом, на выходе из очередного витка мы должны получаем готовый протестированный прототип, который дополняет существующий билд. Прототип, удовлетворяющий всем требованиям – готов к релизу.
3.2 Функциональная модель
(Функциональна модель IDEF0 — методология и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является его акцент на координации объектов. IDEF0 касается логических отношений между заданиями, а не их временной последовательности (WorkFlow). Эта модель является одной из самых прогрессивных моделей и используется при организации бизнес-проектов и проектов на основе моделирования всех процессов, как административных, так и организационных.
Графический язык IDEF0 на удивление прост и гармоничен. Методология основана на четырех основных понятиях: первая из них — концепция функционального блока (Activity Box). Функциональный блок графически представлен как прямоугольник (см. Рисунок 3.6) и олицетворяет определенную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального подразделения следует формулировать в глагольном наклоенении (например, «производить услуги», а не «производственные услуги»). Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:
• Верхняя сторона имеет значение “Управление” (Control);
• Левая сторона имеет значение “Вход” (Input);
• Правая сторона имеет значение “Выход” (Output);
• Нижняя сторона имеет значение “Механизм” (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Ещё интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическое отображение дуги интерфейса представляет собой однонаправленную стрелку. Каждая дуга интерфейса должна иметь уникальное имя (метка стрелки). По требованию стандарта, наименование должно быть оборотом существительного.
В зависимости от того, c какой стороны подходит данная интерфейсная дуга, она называется “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки. В этом случае “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся.
Следует отметить, что любой функциональный блок по требованию должен иметь по крайней мере одну дугу интерфейса управления и одну исходящую. И это понятно: каждый процесс должен выполняться в соответствии с некоторыми правилами (отображается дугой управления) и должен давать некоторый результат (исходящая дуга), в противном случае, его рассмотрение не имеет никакого смысла.)
Рисунок 3.6 – функциональный блок
3.3 Структура ПО
Сервис 4head состоит из трёх основных компонентов:
• Клиентская часть веб приложения – представляет собой графический интерфейс. Это та часть, которую пользователь видит на странице. Графический интерфейс отображается в браузере. Пользователь работает с веб-приложением именно через браузер, нажимая по ссылкам и кнопкам.
• Серверная часть веб-приложения – представляет собой программу или скрипт на сервере, который обрабатывает запросы пользователей (точнее, запросы браузера). Чаще всего серверная часть веб-приложения программируется на PHP но в данном случае был выбран NodeJS. При необходимости в данных, клиентская часть отправляет запросы к серверной части. Сервер обрабатывает этот запрос, получая еобходимые данные из БД и возвращает их клиенту в виде JSON ответа. Клиентская часть в браузере, обрабатывает полученный результат формируя при его помощи новое представление в виде новых элементов веб-страницы.
• База данных (БД, или система управления базми данных, СУБД) — программное обеспечение на сервере, занимающееся хранением данных и их выдачей в нужный момент. В случае форума или блога, хранимые в БД данные — это посты, комментарии, новости, и так далее. База данных располагается на сервере. Серверная часть веб-приложения обращается к базе данных для извлечения данных, которые нужны для формирования страницы, запрошенной пользователем.
3.4 Проектирование БД
В web приложениях как правило за проектирование БД отвечает какая-либо из ORM. ORM (англ. Object-RelationalMapping, рус. объектно-реляционное отображение, или преобразование) — это технология программирования, которая связывает базы данных с концепциями объектно-ориентированных языков программирования, создавая «виртуальную объектную базу данных». Существуют как проприетарные, так и свободные реализации этой технологии. Так же ORM очень сильно помогает при миграции базы данных с одной версии на другу, осуществляя это безболезненно для существующих данных
В нашем случае для того, чтобы спроектировать БД нам нужно создать классы на уровне backend приложения на основе которых ORM ответственная за проектирование создаст необходимые сущности в базе данных, но для начала нужно выделить основные сущности хранимых данных.
Основные сущности данных в приложении:
• User – пользователь системы
• FeedHost – социальная сеть из которой будет происходить загрузка данных
• FeedSourceисточник социальной сети из которой непосредственно будет происходить загрузка (лента группы, пользователя и т.д.)
• Feed – основная сущность содержащая информацию о загруженной единице данных из источника
• FeedFile –файлов который был прикреплен к сущности Feedв источнике
• FeedLike – метка избранной оставленная пользователем к сущности Feed
• FeedComment – комментарий к сущности Feedоставленный пользователем
• FeedCommentLike — метка избранной оставленная пользователем к сущности FeedComment
• Tag – доступный тег
• FeedTag – Сущность Tagприкрепленная к сущности Feed
Описав основные сущности в приложении, можно сгенерировать сущности базы данных: ER-модель БД (рис. 3.7) и FA-модель БД (рис. 3.8.).
Рисунок 3.7 – ER-модель БД
Рисунок 3.8 – FA-модель БД
3.5 Проектирование интерфейса пользователя
Проектирование интерфейса пользователя занимает важную роль в разработки программного обеспечения, ведь от него зависит насколько программа будет интуитивно понятна конечному пользователю.
Ясность — это первая и самая главная задача любого интерфейса. Чтобы интерфейс эффективно помогал людям добиваться своих целей, он должен обладать следующими характеристиками.
• Во-первых, он должен быть узнаваемым, а его назначение — очевидным для пользователя.
• Во-вторых, люди должны понимать, с чем они взаимодействуют через интерфейс.
• Наконец, процесс взаимодействия с интерфейсом должен быть предсказуемым. В интерфейс можно внести некую загадочность или элементы игры, но вот путаницы быть не должно.
Для проектирования интерфейса важно понимать почему было принято то или иное решение, ведь если ошибиться, то у пользователя могут возникнуть проблемы с пониманием продукта.
Для проектирования интерфейса существует множество различных программ, ведь все в голове удержать невозможно и порой, увидев визуально какой-либо из решений, можно понять будет ли оно удобно конечному пользователю или нет, поэтому для проектирования интерфейса воспользовались приложением Figma.
Рисунок 3.9 — Главная страница приложения
Рассмотрим интерфейс поподробнее. Слева располагается главное меню приложения, на нем мы видим изображение текущего пользователя, имя пользователя и его роль в данной системе, под ним расположились разделы главного меню, навигация, уведомления и настройки, в данном случае открыт раздел навигации в котором мы видим основные разделы приложения.
Во всех разделах приложения отображается лента с основным контентом, лента состоит из карточек, в верхней части которой отображено изображение группы, её наименование, время создания записи в источнике. Далее текст записи, под текстом размещено прикрепленное изображение. Если их несколько, то появляются стрелки слева и справа позволяющие перелистывать контент, далее идет, индекс популярности записи, количество просмотров и количество людей которым это запись понравилась. В нижней части карточки расположен список авто сгенерированных тегов и кнопка раскрытия комментариев. Комментарии раскрываются справа и закреплены за карточкой таким образом что при пролистывании страницы комментарии движутся вместе с карточкой. В комментариях есть возможность добавить комментарий и отредактировать его.
Окно авторизации, изображенное на Рисунок 3.10 – Окно авторизации содержит поля для авторизации через emailи пароль, а также возможность войти через социальную сеть.
Рисунок 3.10 — Окно авторизации
В окне регистрации, изображенном на Рисунок 3.11, есть возможность зарегистрироваться в системе введя email, пароль и повторный пароль во избежание ошибочного ввода пароля, либо, все так же можно войти в систему через социальную сеть.
Рисунок 3.11 — Окно регистрации
5 Тестированиее
Проверка всех текстов на соответствие правилам языка.
Будь то русский или любой другой язык, каждый текст, выложенный на сайте, должен соответствовать его правилам: орфографическим, пунктуационным, должны быть строго соблюдены грамматические и лексические нормы. Это касается всего текстового контента – не только больших статей, но и коротких заголовков страниц, надписей на кнопках и пр. Текст на сайте на русском языке и он полностью соответствует правилам языка.
Просмотр сайта на мониторах с разным рарешением.
С разрешением 800 * 600 графика не изменилась, текст выглядит большим, хорошо читается. Изображения не помещаются в экран полностью, появляется полоса прокрутки, что значительно ухудшает просмотр сайта, что не удобно использовать: текст сжимается и увеличивается по длине. Многие страницы не соответствуют размеру экрана, нам нужно прокрутить нижний слайдер, чтобы мы не увидели половину информации на этой странице.
С разрешением 1024 * 768 графика не изменилась, текст выглядит совершенно ясно, хорошо читается. Изображения имеют лучшее качество: не так сильно рябят в глазах, пиксели менее заметны, изображения выглядят лучше, и с этим разрешением гораздо удобнее работать с сервисом. Но многие страницы не соответствуют размеру экрана, вам нужно прокрутить нижний слайдер, чтобы мы не увидели некоторую информацию на этой странице.
При разрешении 1280 * 1024 графика не изменилась, текст выглядит небольшим, хорошо читается. Изображения полностью вписываются в экран, причем это разрешение работает лучше всего. Все страницы соответствуют экрану, и нет никаких неудобств.
Проверка скорости загрузки сайта.
Размер страниц сайта не должен быть слишком большим, а скорость загрузки обязана быть максимальной. От того, насколько быстро загружается сайт, во многом зависит его посещаемость – никому не нравится ждать подолгу. Проверять скорость загрузки можно с помощью инструмента Google. Она относится к факторам ранжирования, поэтому обращайте внимание не рекомендации Google – поисковик сам подскажет, как можно улучшить ситуацию. После проверки времени загрузки по wifi со скоростью 100 мб/с в Explorer 9.0 загрузка занимает не более 5-6 секунд. При работе с другими страницами сайта загрузка также была минимальной и не заставила нас долго ждать. В браузере Opera 12.11. загрузка страницы заняла не более 3-4 секунд, работа с другими страницами была такой же быстрой. В Mozilla Firefox скорость была такой же, как в предыдущем браузере. В браузере Google Chrome же страница загрузилась за 4 секунды.
Проверка сайта в разных браузерах.
При просмотре сайта в браузере Explorer 9.0 можно выделить следующие характеристики:
• читаемость текста отличная, без искажений, кодировка показывается правильно;
• картинки отображаются нормально;
• кнопки работают правильно;
• все скрипты загружаются правильно;
• сайт функционирует полностью.
При просмотре сайта в браузере Opera 12.11. можно выделить следующие характеристики:
• картинки отображаются полностью;
• читаемость текста чёткая, без искажений; ·не работает запись в файл и его чтение;
• тест работает исправно.
При просмотре сайта в браузере Mozilla Firefox, можно выделить следующие характеристики:
• картинки отображаются полностью;
• читаемость текста чёткая, без искажений;
• не работает скрипт запись в файл и его чтение;
• тест работает исправно.
При просмотре сайта в браузере Google Chrome, можно выделить следующие характеристики:
• картинки отображаются полностью;
• читаемость текста чёткая, без искажений;
• не работает скрипт запись в файл и его чтение;
• тест работает исправно.
ЗАКЛЮЧЕНИЕ
Только приложения могут сделать любую операционную систему пригодной для работы, развлечения, выхода в Интернет, просмотра веб-страниц и много другого. Корректно разработанный сервис позволяет пользоваться данным сервисом максимально и полностью быть удовлетворенным его функциональным возможностям.
В данном дипломном проекте рассмотрены актуальные вопросы разработки и создания сервиса «4head» для группировки информации из социальных сетей для дальнейшего предоставления ее конечному пользователю вне зависимости от типа контента.
В процессе достижения поставленной цели были выполнены следующие задачи:
• Изучена предметная область
• Составлено назначение для разработки
• Изучены требования к программе
• Выбраны инструменты для разработки
• Спроектированы БД и интерфейс пользователя
• Разработан сервис «4head»
Таким образом, следует считать, что результаты разработки соответствуют всем требованиям технического задания, поставленная цель достигнута. Работа носит законченный характер.
Сокращения, обозначения, термины и определения
БД – база данных.
ПО – программное обеспечение.
OAuth 2 – это протокол авторизации, который предоставляет приложениям ограниченный HTTP-доступ к учетным записям пользователей. Он передаёт аутентификацию пользователей сервису, на котором размещены учетные записи, и авторизует сторонние приложения и передаёт им доступ к учетной записи пользователя. OAuth 2 обеспечивает авторизацию веб-приложений и мобильных устройств.
PHP – язык программирования, специально разработанный для написания web-приложений (скриптов, сценариев), исполняющихся на Web-сервере.
HTML — это язык разметки гипертекста. И хотя от многих можно услышать, что это язык сетевого программирования, на самом деле это не так. Подчеркнем, что это формат разметки, который используется для того, чтобы сформировать веб-документ из контента разного типа.
ORM или Object-relational mapping (рус. Объектно-реляционное отображение) — это технология программирования, которая позволяет преобразовывать несовместимые типы моделей в ООП, в частности, между хранилищем данных и объектами программирования.
Браузер — (WEB-браузер) – это программа, которая обеспечивает просмотр Интернет-сайтов на компьютерных устройствах и гаджетах.
Front-end разработка – это работа по созданию доступной всем части сайта, с которой пользователь контактирует напрямую и с функциями, которые обычно воспроизводятся на стороне клиента (в браузере)
Бэкэнд development – это процесс программирования сайта и наполнения его функционалом. Создание ядра сайта, разработка платформы сайта, наполнение его основным функционалом и создание административной зоны – это и есть бэкэнд разработка.
Социальная сеть (англ. social network) – это веб-сервис, обслуживающий процесс удаленного взаимодействия между людьми и объединяет пользователей по конкретным признакам. Это интернет-сообщество, созданное для оптимизации общения между людьми с целью объединить на одном ресурсе пользователей, имеющих общие интересы.(например фильмы, любители животных)
Node.js (или просто Node) — это серверная платформа для работы с JavaScript через движок V8. JavaScript выполняет действие на стороне клиента, а Node — на сервере. С помощью Node можно писать полноценные приложения. Node умеет работать с внешними библиотеками, вызывать команды из кода на JavaScript и выполнять роль веб-сервера.
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
1. Array Интернет и семантический WEB; Ленанд — М., 2008. — 104 c.
2. Jesse Russell Жас Отан; VSD — М., 2012. — 172 c.
3. Ахромов Я. В. Системы электронной коммерции; Оникс — М., 2007. — 416 c.
4. Винарский Я. С., Гутгарц Р. Д. Web-аппликации в интернет-маркетинге. Проектирование, создание и применение; ИНФРА-М — М., 2015. — 270 c.
5. Голощапов Алексей Google Android. Программирование для мобильных устройств; БХВ-Петербург — М., 2012. — 448 c.
6. Гробов Игорь Разработка Web-портала в ASP.NET 2.0 и SharePoint 2007 (+ CD-ROM); БХВ-Петербург — М., 2008. — 656 c.
7. Дригалкин В. В. Веб-сайт на 100%. Как создать веб-сайт и сделать его видимым в Интернете; Вильямс — М., 2010. — 224 c.
8. Дунаев Вадим Web-программирование для всех; БХВ-Петербург — М., 2008. — 168 c.
9. Евдокимов Н.В. Раскрутка веб-сайта. Практическое руководство; Диалектика — М., 2012. — 477 c.
10. Жвалевский Андрей Создание и раскрутка сайта без напряга; СИНТЕГ — Москва, 2012. — 759 c.
11. Журнал Открытые системы. СУБД №3; Открытые Системы — М., 2012. — 686 c.
12. Кармен Делессио Создание приложений для Android за 24 часа; Эксмо — М., 2015. — 780 c.
13. Ленгсторф Джейсон PHP и jQuery для профессионалов; Вильямс — М., 2011. — 362 c.
14. Майк Ганделрой ADO и ADO.NET. Полное руководство (+ CD-ROM); Корона-Век — М., 2011. — 507 c.
15. Макаров Александр Yii. Сборник рецептов; ДМК Пресс — М., 2015. — 372 c.
16. Машнин Тимур Web-сервисы Java; БХВ-Петербург — М., 2011. — 893 c.
17. Мобильная разработка. Галерея шаблонов; Питер — М., 2013. — 192 c.
18. Низамутдинов Марсель Тактика защиты и нападения на Web-приложения (+ CD-ROM); БХВ-Петербург — М., 2005. — 432 c.
19. Петин Виктор Сайт на AJAX под ключ. Готовое решение для интернет-магазина; БХВ-Петербург — М., 2012. — 448 c.
20. Рассел Джесси Волков, Евгений Новомирович; VSD — М., 2012. — 717 c.
21. Рассел Джесси Языковые разделы Википедии; VSD — М., 2012. — 560 c.
22. Ромашов Виктор CMS Drupal. Система управления содержимым сайта; Питер — М., 2010. — 946 c.
23. Рэбхэн Бенджи От кликов к продажам. Как повысить продажи через оптимизацию конверсии; ИЛ — Москва, 2013. — 515 c.
24. Сергеенко С.В. Разработка и проектирование Web-приложений Oracle Developer; Бином. Лаборатория знаний — М., 2014. — 733 c.
25. Сухов К. К. Node.js. Путеводитель по технологии; ДМК Пресс — М., 2015. — 646 c.
26. Форсье Джефф Django. Разработка веб-приложений на Python; Символ-плюс — М., 1998. — 413 c.
27. Фримен А. LINQ. Язык интегрированных запросов в C# 2010 для профессионалов; Диалектика / Вильямс — М., 2011. — 381 c.
28. Фултон Х. Программирование на языке RUBY; Книга по Требованию — М., 2007. — 686 c.
29. Хоган Б. HTML5 и CSS3. Веб-разработка по стандартам нового поколения; Питер — М., 2014. — 505 c.
30. Шкляр Леон , Розен Рич Архитектура веб-приложений; Эксмо — М., 2011. — 640 c.