[Powered by Google Translate] [Семинар] [Веб-разработка: От идеи до воплощения] [Бен Kuhn] [Билли Janitsch] [Гарвардский университет] [Это CS50] [CS50.TV] [Билли] Привет, я Билли и это Бен. >> [Бен] Привет. Мы собираемся говорить о веб-разработке и сегодня. [WebDev] [Билли Janitsch и Бен Kuhn] Немного о нас в первую очередь. Бен является своего рода фоновых парнем. Он делает все это работает. А потом я иду в и сделать их довольно. Я в значительной мере участвует с большим переднего плана дизайна макета рода вещи, и Бен, с другой стороны, знает, что он делает, чтобы он работает на серверной вещи. Вместе мы сделали несколько вещей. Например, в прошлом году мы работали над Gimblium который представляет собой интернет-студия разработки игр. Это была наша окончательный проект для класса, и с тех пор мы сделали Гарвардского Class которая представляет собой интернет-база для просмотра и торговых курсов в Гарварде. 

Мы собираемся начать с этой идеей для нашего сайта. Мы собираемся сделать Facebook, но для кошек. Перед тем, как на самом деле сделать этот сайт, не сделать этот сайт, потому что это не очень хорошо, но мы будем использовать ее в качестве основы и пройти через процесс, как мы берем эту идею и превратить его в настоящий веб-сайт, мы можем использовать. Мы начнем, нарушая сайт вниз. Как вы делали в CS50, вы хотите думать о том, что фактические компоненты, которые входят в этот веб-сайт. В основном превратив его из идеи, которая является только вид абстрактное понятие в реальные, ощутимые вещи, которые вы могли бы сделать. Начнем с вопроса несколько вопросов. Что это за сайт? Почему мы делаем это? Что он собирается использовать для? Такого рода вещи. В случае Facebook Cat, мы в основном хотите сайт, который позволяет кошек социальной сети друг с другом. Идея в том, что они могут разместить на стенах друг друга, они могут сделать комментарии, такие вещи. И вот, когда мы придем в функциональных компонентов. Теперь у нас есть этот вид рамках - у нас есть профили пользователей, у нас есть комментарии, и мы можем отправить. Возможно, когда-нибудь мы будем влиятельных любит и такую ​​вещь. И мы как бы хочу приоритеты этим возможностям дюйма Мы хотим сказать, что, ладно, это действительно важно, чтобы у каждого есть профиль и что каждый может разместить на стенах друг друга. Вторичный к тому, что, комментарии были бы хороши. Может быть, позже мы влиятельных любит. Итак, вы хотите, чтобы иметь представление о том, что это основополагающее значение для вашего проекта а что это за более общей функции, которые могут быть применены позже. Вы хотите, чтобы рода есть определенный список в виду, но проект, что вы начинаете с не будет проект, который вы закончите с. Другими словами, все будет меняться, пока вы разрабатываете сайт, и вы хотите, чтобы оставить место для этого. Я верну его на Бена, который собирается рассказать немного о структуре. 

[Бен] я собираюсь говорить о более технической стороне веб-разработки. Давайте просто пойти над некоторыми основами в первую очередь. Когда вы делаете веб-приложение, Главное управление, что вы будете иметь, чтобы есть, Вы будете иметь некоторые вещи происходит в клиентской стороне - то есть, код, который вы браузеру берет с сайта и JavaScript, HTML, CSS материал. Вот и все на стороне клиента. Вы будете иметь другой код, который работает на стороне сервера которая отслеживает все данные, которые люди посылают к вам, решает, кто дать то, что, все в таком духе. Это лишь некоторые термины, чтобы вы, ребята, все знакомы с тем, что мы говорим о. Помимо этого подразделения, что это хорошо, чтобы думать о своем веб-приложение с точки зрения пару различных компонентов. Когда вы делаете веб-разработки одна из вещей, которые вы должны всегда быть пытаются сделать, это уменьшить сложность. Чем сложнее код, тем больше шансов, чтобы сделать ошибки, тем труднее изменить позднее. Так что, если вы можете разбить ваше приложение в некоторых отдельных функциональных областей что будет - и вы можете уменьшить рода размере кросс-области связи - что поможет вам многое в долгосрочной перспективе с точки зрения сокращения ошибок. 

Чтобы быть конкретным, как правило, люди делят веб-приложение в - это своего рода модных слов сейчас, но они все еще полезны. Возможно, вы слышали люди говорят о моделей, представлений и контроллеров. Модели являются фактические данные, что ваше приложение собирается иметь дело. Например, в вашем Cat Facebook, ваши модели будет - Вы должны были бы модель как сообщений, а также модель для профилей пользователей, все в таком духе. Ваши взгляды, как Вы представляете, что данные для пользователей. Возможно, вам придется 1 вид для глядя на одной должности и все комментарии и иной взгляд на вашей стене, что имеет список всех сообщений , которые направлены на вас, и другой вид для вашего новостей - все в таком духе. Наконец, у вас есть контроллеры, которые в основном, когда люди посылают вам сообщения и вы делаете обновления для вашего серверной системе, Вы увеличить кучу счетчиков, и что угодно. Это ваши контроллеры. 

Я собираюсь говорить в основном о моделях. Просмотров технически не так сложно, а речь идет больше с их разработке Контроллеры будут специфическими для того, что Вы проектировании. Но есть некоторые довольно общие методы можно использовать чтобы сделать ваши модели приятнее и легче работать с, что я думаю, что очень полезно. Это в основном будет о том, как иметь дело с вашими данными веб-приложений в хороший способ. Основные вопросы, с моделями в том, что они живут на клиенте и на сервере, и вы должны выяснить, а) как их получить - все соответствующие те - от сервера к клиенту, и б) как держать их в синхронизации. Ваши пользователи будут хотеть, чтобы сделать некоторые обновления. Они собираются хотим сделать новые сообщения. Они собираются хочу любить вещи и вещи, если у вас есть симпатии. Таковы основные технические проблемы борьбы с моделями. Первое, что вы собираетесь хотите спросить себя, какие данные идет в этой модели и какие запросы мы собираемся хотите сделать - то есть, как мы будем смотреть на моделях? Для вашего Cat Facebook Например, ваш пост будет иметь автору, связанные с ним, некоторые стене текст и получателем сообщению стены. И тогда вы, возможно, захотите запросить, что в кучу-разному. Вы хотели бы, чтобы смотреть на него тем, кто писал, какой пост, тем, кто получил какую должность, может быть, по дате их были размещены. Но если вы собираетесь сделать это по дате, то вы должны добавить еще одно поле на свой пост от того, когда он был на самом деле отправил. Эти 2 фактора - то, что данные, которые вы хотите использовать и как вы хотите, чтобы посмотреть его - вы должны думать о них в первую очередь потому, что они зависят друг от друга, и это будет сложнее, чтобы добавить их в дальнейшем. 

Есть и другие соображения. Когда вы думаете о том, как вы имеете дело с моделями на сервере то, что вы хотите посмотреть на это - вы в основном хотят, чтобы сервер как можно более простым. Делая вещи на стороне клиента, как правило, гораздо быстрее, если вы можете сделать это чисто на клиенте не делая каких-либо запросу сети. Идея состоит в том, чтобы делать то, что многие из этих запросов, как вы можете на клиенте. Единственная проблема с этим является то, что если вы спрашиваете все ваши данные в начале то, что собирается занять много времени для загрузки. Таким образом, идея заключается в золотую середину между наличием достаточного количества данных на стороне клиента что вы можете сделать большую часть работы там, но не только извлечение все сразу так что вы получите действительно медленные время загрузки в начале. Например, для данных кошки Вы, наверное, хотели, чтобы принести кучу последних сообщений стены. Вы не хотели бы, чтобы принести все из них, потому что это может вернуться через пару лет. Но вы не хотите, чтобы принести им по одному потому что это ввести много сетевые накладные расходы. 

Это часто довольно трудно - как только у Вас работает с базой данных - часто довольно трудно изменить, какие данные у вас есть в нем - то есть, добавить новый столбец базы данных или что-то - так что хорошая стратегия на самом деле просто держать много ваших данных в текстовом капля - капля JSON - JSON быть JavaScript Object Notation - Причина, по которой это полезно, потому что тогда вы можете добавить новые свойства на все эти JSON капли не меняя вашу базу данных. Единственный недостаток, что в том, что если у вас есть куча полей что вы добавлены позже - как скрытые в этой JSON капля - то это сложнее запросить их в базе данных. Например, если вы позже - если у вас был свой пост модель, что мы обсуждали ранее только с автором, получателя и текст - Вы могли также есть JSON каплю, а затем, если вы позже хотел добавить поле даты Вы не должны были бы изменить ваши базы. Вы можете просто добавить даты, чтобы все текстовые поля. И тогда вы были бы в состоянии смотреть на тех, кто на стороне клиента, но вы не были бы в состоянии запросить их на стороне сервера потому что это скрыто внутри этого текста. 

Другой вопрос, что вы хотите, чтобы думать о как ваш клиент, и сервер собираетесь общаться. Вы, как правило, хотят, чтобы эта как можно более простым. Вы можете просто как краткосрочного меня-этого запроса данных, Create-A-New-Object вещь, и запрос на обновление-старый-объект. И это все были бы разные URL-адреса на сервере, вы - , что браузер будет - вы можете использовать AJAX запросы для всех из них и либо принимать, либо разместить данные. Опять же, для нашей кошки Facebook Например, вы могли бы иметь, что URL, чтобы получить индивидуальный пост, и у вас был бы URL для создания новой записи стены и, возможно, URL для загрузки своей фотографией в профиле, такие вещи, как, что. Но опять же, это заранее получить большинство ваших данных, так что вам не придется держать создание сетевых запросов. По этой причине, вы не можете иметь, что индивидуальный запрос получить за одно сообщение, и вместо этого вы просто хотите 1 запрос получите за всю стену. А потом, если вы пытаетесь найти баланс, потому что - это также будет зависеть от вашего приложения. Потому что если вы ожидаете, что люди имеют только 10 или 20 сообщений на стене что все будет хорошо. Но если вы ожидаете они имеют тысячи тогда, что запрос займет слишком много времени, и так что вы можете добавить Get-все-сообщения-так параметр. 

Для всех из них вы, вероятно, будете хотеть, чтобы синхронизировать данные в JSON - JavaScript Object Notation. Практически каждый язык имеет дело с JSON очень хорошо. JQuery имеет эту хорошую функцию getJSON, который будет делать всю тяжелую работу за вас. И на PHP есть также очень хорошие функции JSON связи. Так, это, вероятно, лучший формат для отправки модели взад и вперед. 

В качестве примера того, что мы говорили о до сих пор, вот пример потока для вашей кошки Facebook приложения. Она начинается с вашего браузера, запрашивающего база адрес веб-сайта. Сервер, вероятно, пошлет за статический HTML и немного JavaScript и CSS. Как правило, лучше не делать никаких рендеринг на сервере. Вы, наверное, не хотите - что сервер не делает там идет вниз список сообщений стены и создать некоторый HTML для каждого из них и отправки, что за. Как правило, лучше делать это на стороне клиента, так как в противном случае каждый раз, когда вы хотите, чтобы повторно нарисовать что-то, вы должны сделать запрос на сервер. И, что очень быстро дает много накладных расходов. Как правило, лучше всего, чтобы корабль посылает статический HTML а затем JavaScript и CSS, которые будут выполнять рендеринг на стороне клиента. Как только тот материал приходит, то вы можете иметь - в JavaScript - вы можете сделать запросы для данных стене и все в таком духе, и после, что сервер в основном только делать запросы к базе данных и проверки прав доступа. Важно только то, что он не может отправить по некоторым другими пользователями сообщений на стене что вы не можете видеть. Он может быть в основном очень тонкий слой доступа к базе данных, а затем все, показывающий данные - все представления и прочее - те, может произойти в вашем браузере, а затем, когда вы хотите сделать пост или что-то Вы просто отправить еще один запрос. 

Там также некоторые модные вещи вы можете сделать на вершине этого. С точки зрения получения более подробной технической информации, развивается в обычной JavaScript может быть немного болезненным, поэтому, есть некоторые библиотеки и инструменты, которые помогут вам много с этим. Я думаю, что вы все, наверное, слышали о JQuery что делает делает HTML рендеринг и манипуляции намного проще - есть много фантазии функций для увядающей, и выйдет, и делать как дизельные анимации. Там также эта библиотека называется Underscore.js. Она имеет много полезных функций полезности, вещи, которые вы ожидали бы JavaScript, чтобы иметь что это действительно оленья кожа - такие вещи, как перетасовки массив, удаление дубликатов из списка, или уплощение список списков. Это лишь небольшой пример кода. Подчеркивание имеет массу этих хороших функций, которые вы хотите вам придется все время. 

А тут еще более 1 библиотека, что я хотел бы провести немного времени на называется Backbone.js потому Магистральная действительно помогает вам справиться с моделями на стороне клиента и много путаницы, что это может вызвать. Магистральная дает эту концепцию моделей и коллекций в JavaScript, которые в основном так же, как объектов JavaScript в массивах JavaScript, но у них есть события, когда вы изменить свои свойства. Так же, как в JavaScript, вы можете иметь событие, когда кнопка получает нажал или что-то эти модели Магистральные и коллекции Магистральные будет транслировать вещи, как , что, когда они изменяются. Это означает, что вы можете просто написать что-то вроде этого фрагмент кода здесь - это говорит, когда вы что-либо добавить к записям массива вы перекроить всю стену. И это было бы сказать, всякий раз, когда число поста из подобных изменений, Вы уведомить пользователя, что кто-то любил свой пост. Или когда любое имущество должности изменения вы перекроить пост. Вещи, как, что сэкономит вам кучу сложности, потому что иначе если у вас нет Некоторые рамочные как это, то каждый раз, когда в коде, что вы изменить что-нибудь о должности, вы должны были бы помнить себя называть все делают функции и все в таком духе, и если вы хотели добавить что-то новое, что произошло каждый раз, когда вы изменили пост вам придется пройти через каждый место в вашем код, который вы изменили пост и добавить, что новую вещь. Рамки, как это будет удалить много, что между слоем связи что делает ваш код сложным и трудно поддерживать. 

Там в немного о взглядах тоже. Я собираюсь оставить большую часть этого Билли, потому что они технически не очень сложно. Используйте JQuery за просмотр. Это практически как необходимость в этой точке. Он просто делает все намного проще. Есть много библиотек. Если вы усложнили элементы пользовательского интерфейса, если вы хотите автозаполнения вещь или, как один из тех причудливых мульти-селекторов - если вы хотите что-нибудь подобное, вы должны, вероятно, просто искать вокруг и вы можете найти хорошую библиотеку, которая будет делать то, что вы хотите. Билли объяснит больше о фактически трудных частей видом. Кроме того, как примечание стороны, Магистральная имеет некоторые функциональные возможности для принятия просмотров общаться приятно с моделями - посмотрите документацию для всех этих библиотек, на самом деле. Достаточно взглянуть на документы. Они очень хорошо написана и легко следовать. В общем, вы можете в значительной степени только Google, если у вас есть проблемы. Есть много людей, использующих их. Я думаю, что это как последнее замечание. 

Есть также некоторые более продвинутые вещи, которые вы можете сделать, если вы ищете, чтобы сделать ваш веб-приложение дополнительные удивительным. Вы можете сделать - новая спецификация HTML5 имеет много причудливых вещей, которые вы можете сделать. Локальное хранение данных - что вы можете хранить данные в браузере - вместо того, чтобы вернуться назад и просмотреть сервер за все, Вы можете держать некоторые из них на стороне клиента и, что даже позволяет людям - в некоторых случаях она может даже позволит вам использовать веб-страницы в автономном режиме. Там в то, что называется WebSockets которые являются различного рода сетевых коммуникаций где вместо того, чтобы просто вы делаете одну заявку, вы получите ответ, и все готово, Вы держите открыть соединение с сервером и поэтому вы можете делать вещи, как обновления в реальном времени. Так что, если вы пытались сделать чат приложение, вы можете использовать WebSockets общаться назад и вперед так, чтобы вам не придется держать с просьбой, "О, сервер, кто-нибудь прислать мне поболтать?" каждые 10 секунд или что-то. Там также интересная HTML5 функция, где вы можете сделать его похожим на Адрес страницы в сети меняется, даже не имея на самом деле перезагрузить его. Вы можете использовать кнопки Назад и Вперед, не делая кучу сетевых запросов. Вещи, как, что действительно полезно с точки зрения, что делает его быстрым, но и работать как веб-приложение должно. 

Там также то, что называется CoffeeScript. CoffeeScript это другой язык, на самом деле, что составляет до JavaScript. Вы должны написать весь код в CoffeeScript, а затем запустить этот компилятор, и он выплевывает файл JavaScript, который можно включить в веб-страницы. Причина, по которой CoffeeScript хорош потому, что он избавляется от многих странные случаи, которые JavaScript имеет, где равна равных, и составляет равно делать разные вещи, или как - он имеет более хорошее синтаксис для работы с массивами и функциями. Это небольшой отрывок из CoffeeScript, которая выдает список всех квадратов от 10 ^ 2 к 1 ^ 2 в обратном порядке. Как вы можете видеть, CoffeeScript часто позволяет выразить в 1 линии что бы взять 5 строк JavaScript. Это может сделать вещи намного проще. Это немного нового синтаксиса, чтобы узнать сначала, но он определенно сделает вашу работу более продуктивной в долгосрочной перспективе. 

Вы также можете использовать другие языки, на сервере, чем PHP - Языки, как Ruby, Python, или есть даже проект под названием node.js что позволит вам использовать наличие на сервере. Лично я очень, очень не нравится PHP. Я просто не нравится работать с ним. Если вы тоже думаете, что это ужасно cluge языка, то вы можете использовать один из них вместо этого. В общем, если вы хотите сделать что-то, и вы действительно не знаете, как бы вы это сделали, просто поиск в Интернете. Есть тонны и тонны ресурсов особенно на - StackOverflow является великим. Именно это сайт, где программисты задавать друг другу вопросы. Вы, возможно, столкнетесь с ним, если вы были проблемы на проблемные CS50 множеств. И есть тонны библиотек для ведения в значительной степени все, что вы хотели бы. Если вы хотите сделать что-то и вы не знаете, как это сделать, не думайте, что это невозможно. Посмотрите вокруг, и вы можете найти некоторые хорошие ресурсы. 

Как вообще подводить итоги, основные вынос являются держать вещи простыми. Чем сложнее код находится в начале и чем больше вы попробовать и сделать модные вещи, тем больше времени потребуется, чтобы получить что-то действительно функциональное и тем труднее будет изменить позже. Так, делать вещи немым, простой способ первый. Чтобы согласиться с этим, не бойтесь того, чтобы выбросить старый код или очистки его много. В общем, как только вы на самом деле есть что-то работает, это гораздо проще думать о чем тогда, когда вы все еще в начальной стадии о том, как бы это сказать все вместе. Лучше всего, чтобы сделать тупой возможное дизайн, который работает а затем улучшить его многократно, чем пытаться получить все правильно с первого раза. С точки зрения разделения клиент-сервер, попытаться сохранить ваш сервер очень просто - просто база данных, а некоторые аутентификации и не делают никакой тяжелой работы там. У всех ваших сложные вещи на стороне клиента в браузере в JavaScript столько, сколько вы можете. Посмотрите вокруг для библиотек, которые делают вашу жизнь лучше. Всегда лучше использовать код, который кто-то написал если вы - и не писать его самостоятельно. Там очень много вещей в Интернете. Google это ваш лучший друг. Google является лучшим другом программиста. Да, безусловно, не бойтесь, чтобы осмотреться на вещи. Хорошо. И к Билли. 

[Билли] На самом деле, прежде чем я начну с некоторыми дизайн вещи, Кто-нибудь есть какие-либо вопросы для Бена ни о чем, что он говорил о? Ладно, хорошо. Опять же, дайте нам знать, если что-нибудь не ясно или если вы хотите, чтобы мы пошли на что-то немного больше. Я собираюсь сделать шаг назад немного, и говорить о более фундаментальных частей конструкции. Бен упомянул модель под названием - извините, Model View Controller система который является своего рода технической стороны, так что я собираюсь смотреть на видом частности, и я собираюсь начать с как бы вы разработать мнение, что выглядит красиво. Вот вид действительно базовый шаблон для нашего кота Facebook. Я думаю, что есть некоторые фундаментальные в современном дизайне пользовательского интерфейса , которые стоит набирает обороты. Вы можете заметить, что есть много белого пространства по всей странице, много места для вещей. Не хочется вас есть, чтобы раздавить вещи в страницу. Вы хотите оставить много места открыты, и если вы идете в почти любой современной сайте вы увидите, что именно белая везде. Там в белый в местах вы не будете ожидать. У вас есть эта цветовую палитру, и это мудро в начале выбрать цветовую палитру, что вы собираетесь работать, и развиваться. Вы также - помогает выбрать шрифт, и, таким образом, вы вроде работы с эти конкретные основы дизайна. У вас есть свой тип, у вас есть свои цвета, а затем вы можете рода соответствовать все остальное в по мере необходимости. Так что, как я уже сказал, с вашей цветовой гамме вы хотите использовать более смелые цвета вашего цветовой гамме экономно. Заголовки хороши. Кнопки хорошо иметь действительно большие, яркие цвета. Но в целом, если у вас есть сайт, который имеет цвета везде, все смотрит вам в лицо, он просто выглядит суматоху, и это не хорошо. Вы хотите, чтобы правило, используют светлые тона. Попробуйте, опять же, выбрать довольно последовательную цветовую схему. Вы можете иметь эти маленькие брызги большим количеством цветов - которые могут выглядеть довольно хорошо, но вы хотите использовать их довольно экономно. 

Как я уже сказал, вы хотите быть минимальным. Менее почти всегда больше. Если вы можете показать что-то или нет отображать что-то, и ты вроде не уверены, следует ли ему быть там по умолчанию - вероятно, Вам лучше всего оставить его. Вы всегда можете добавить его в дальнейшем. Да, держать вещи простыми. Но самое главное, вы хотите рассмотреть несколько проектов. Не думайте, что, когда вы делаете сайт, у вас есть в вашей голове, что вы собираетесь сделать сайт в некотором роде, и это будет выглядеть так же, как это. Это будет иметь синий заголовок в верхней и синий боковую панель а затем желтый вещь подзаголовок. Вы хотите, чтобы несколько шаблонов. Вы можете либо - если вы хорошо с Photo Shop, вы можете открыть, что и рода дизайн сайта, как вам нравится, чтобы она выглядела. Если нет, то вы можете просто использовать ручку и бумагу, но поцарапать до нескольких конструкций. Вы хотите, чтобы в основном имеют настроить, где у вас есть много различных конструкций, и если один заканчивается работу, то это замечательно. Если заканчивается неудачу, то у вас всегда есть еще один, чтобы обратиться. В общем, не чувствую, что вы должны быть ограничены в какой бы то ни дизайн вы изначально решение о. Конструкции очень изменчивы, и часть важности модели вид системный контроллер является то, что вы можете поменять в и разные взгляды, которые вы хотите. Вы можете повлиять свои данные в одну сторону, а затем решить,, ой, на самом деле, это не работает, что хорошо. Я думаю, что это своего рода слишком сложным или есть часть здесь, что на самом деле не работает, так что я просто хочу, чтобы полностью отказаться от этого вида и своп в совершенно новой. Мы все еще можем использовать старые модели и старые контроллеры. Мы можем сделать все на сервере и клиенте, как нам бы раньше. Но фактическое волна данным на дисплее будет немного отличаться. 

Насколько на самом деле реализации дизайн вы хотите, когда у вас есть несколько конструкций набросал на бумаге или на Photo Shop или любой другой, Есть целый ряд инструментов, которые доступны для вас. Первый вы очень хорошо знакомы с которой ваш HTML, PHP, или то, язык вы используете только для кодирования статических страниц на вашем сайте. Вы много работали с HTML, какой вид дает вам эти теги что вы можете положить вещи в, и в основном это способ организации содержимого. Например, у вас есть заголовок там, так что вы будете иметь, тег заголовка, и это будет иметь некоторый текст внутри него, которая, вероятно, будет в другой тег. Тогда у вас есть врезку возможно, с некоторыми разных звеньев, и те собираются все быть в отдельных тегов. Так, в основном HTML в его сердце это способ разделения страницу, как вы в конечном итоге хотите отформатировать его. Итак, еще раз, вы видели, что раньше. Ты очень удобно работать с ним сейчас учитывая, что вы сделали в последний PSET надеюсь, так что не должно быть никаких проблем. 

Тогда у вас есть CSS, который в основном обрабатывает все дизайна статических аспектах. Было бы обрабатывать все цвета, все позиционировании различных элементов, где они идут с относительно друг друга, какие они большие, различные виды позициями, которые вам придется - другими словами, вы можете иметь вещи закреплены так, чтобы, когда вы прокрутите вниз они остаются, или вы можете иметь вещи по отношению к другим элементам. Все такого рода вещи в CSS. Кроме того, вы можете сделать различные украшения, вы можете иметь цвет текста, текстовые эффекты, все в таком же роде. Бен дал действительно хороший семинар на эту минувшие выходные, и поэтому я обязательно проверить бы, что, если вы планируете делать некоторые модные вещи с CSS. CSS3 на самом деле новая версия CSS, и это может сделать все виды действительно хороших вещей. Он может делать градиенты, вы можете иметь хорошие, закругленные углы, вы можете сделать все виды материала чтобы сделать ваш сайт выглядеть более современными и фантазии. 

Следующий инструмент JavaScript и JQuery, который Бен немного поговорили о, но я получу немного дальше в. JavaScript, как вы работали с ним немного, или по крайней мере видели это в лекции, это своего рода способ динамически делать вещи в HTML. HTML, как вы знаете, является статическим, поэтому, как только у вас есть HTML вы не можете изменить его. Но в JavaScript, в некотором смысле, это способ быть в состоянии изменить HTML. Таким образом, вы можете сделать это, и это здорово, но JavaScript действительно боль, чтобы работать с. Это так долго и тупой и делать даже самые простые вещи требует много линий JavaScript. Так, JQuery в основном это библиотека для JavaScript, который упрощает все это. Это говорит, хорошо, если вы хотите иметь квадратную коробку раздается из левого и отходят на второй странице, так что это не находится в середине, в JavaScript, который возьмет - Я не знаю,, сто линии, чтобы сделать, и это будет боль, и вы выходите из его ненавидеть все о веб-программировании. JQuery вы в основном имеют элемент-точка-ЧЕТКО, или что-то вроде этого. Так, очень, очень простые функции, которые позволят вам сделать все виды анимацию и такая вещь. Другое дело, что эти 2 очень хорошо для просто делает динамические вещи с веб-сайтом. Так, а не просто иметь свой страницу HTML - который отображает некоторые данные, но на самом деле не ничего делать - JavaScript и JQuery позволит Вам иметь кнопки, вы можете нажать на, и вы можете перетаскивать элементы и переупорядочиваем их и сортировать их, и имеют новые элементы добавлены или удалены. Вы можете добавить-удаления, такого рода вещи. Так, JQuery делает тонн интересных вещей. И Випул фактически давая семинар по этом сегодня, на мой взгляд, в 5-часов, так что если вы можете остаться на так долго, что бы - 5 или 4? Четыре. Извините. Это на самом деле сразу после этого, поэтому я бы рекомендовал прилипания вокруг для него, если можно. JQuery супер, супер полезно, и вы будете в состоянии сделать много действительно хороших вещей с ним для почти любого проекта веб-разработки. 

Теперь я собираюсь попасть в своего рода различия. Я говорил в основном о пользовательском интерфейсе. Пользовательский интерфейс является только дизайн сайта. Но есть своего рода еще одна концепция, которая является пользовательский опыт. Два очень разные. Интерфейс, безусловно, часть опыта. Другими словами, когда вы заходите на сайт, вы посмотрите на интерфейс. Это часть того, как вы испытываете на сайт. Но пользовательский опыт более того. Опыт Пользователь о том, что создается впечатление, что пользователь получает с вашего сайта есть. Таким образом, очевидно, интерфейс является частью этого. И это, безусловно, необходимая часть, но это не достаточно. Другими словами, если у вас есть приятный интерфейс, и это довольно и красочный, и все, что, это здорово, но если пользователь переходит на ваш сайт, видит симпатичную макет, и это смущает все, понятия не имеет, как что-либо делать, то, очевидно, вы сделали действительно бедных сайт. Это своего рода, где пользовательский опыт приходит дюйма Я собираюсь рассказать немного о UX дизайн - UX это сокращение от пользовательского опыта - и вроде как вы можете убедиться, что у вас есть хороший опыт пользователя. Первый заключается в том, что вы можете разработать сайт, где пользователь может делать все, что что пользователь, возможно, хочет. Но если пользователь не может понять, как делать те вещи - другими словами, если пользователь не есть хорошая идея, когда они идут на ваш сайт из, "О, если я хочу обновить свой профиль, то я нажимаю эту кнопку, или если я хочу разместить на чей-то стена, то я иду в их стене и нажмите на коробочку ". Если пользователь не знает, что, то вы эффективно имеют на самом деле не реализованы эту функциональность правильно. Часть реализации функциональности является то, что пользователи на самом деле в состоянии использовать его. И это может быть неприятно - вы можете сделать сайт, и он может сделать все виды замечательные вещи, но тогда вы будете иметь людей проверить его и сказать: "Это не может этого сделать. Почему он не может это сделать? ", И вы будете говорить, вернуться к ним, "Ну, он может. Вы просто должны пойти в меню седьмой выпадающего на этот никому не известный страницы, что только можно найти на ссылку в правом нижнем углу "или что-то. Очевидно, вы не хотите, что. Вы хотите, чтобы это было понятно для пользователей, что они должны делать, и она должна быть простой и интуитивно понятный для них. 

Другое дело, что вы хотите, чтобы попытаться сделать, это, если кто-то собирается идти на ваш сайт и 9 из 10 раз сделать действие А, и 1 из 10 раз сделать действий B, вы, вероятно, хотите, чтобы сосредоточиться своим опытом действий А. Другими словами, вы хотите сделать это очень, очень ясно, как это сделать A. Должна быть передняя-центровой - зайти на сайт, посмотреть ее; о, это тут же. В то время как B, очевидно, вы хотите быть понятно, но вы можете оставить его немного больше в фоновом режиме. Дэвид дает хороший пример этого в лекции, которая является системой Boston T. Когда вы идете в Бостон T, и вы хотите, чтобы купить билет, Вы должны войти в 5 меню, прежде чем вы действительно сможете приобрести билет для значения в $ 2, $ 2.50, что является, сколько нужно, чтобы ездить в метро в одном направлении. Это проблема, потому что большинство людей, которые езда в метро вероятно, просто хочу, чтобы пойти в одном месте, купить свой билет, попасть на сразу. Это не имеет смысла, что они должны пройти через множество различных меню туда попасть. Лучший пользовательский опыт будет быстрая кнопка на первой странице что просто говорит: "купить билет в один конец на", и, что бы поставить во всех стандарта значения по умолчанию, а затем, если кто-то хочет купить другую билет, чем, они все еще, конечно, есть возможность, но вы оптимизировали для общее использование случай, который является действительно важным. Вы можете видеть примеры этого на Facebook, не так ли? Если вы идете в Facebook, и вы хотите опубликовать статус, это правильно наверху, который является то, что вы часто хотят сделать. Как только вы войдете в страницу, вы можете сделать самые общие вещи, которые что вы хотите сделать. Если вы хотите сделать немного более сложные вещи, как, сказать, что я хочу пойти в стене моего друга и отправить фотографию на нем - который я хочу сделать часто, но не так часто, как размещение обновления статуса - так что в этом случае, я печатаю его имя в поле в верхней, нажмите на их профиле, а затем, все же, это на самом верху там однажды я получил в свой профиль. Опять же, я оптимизированы в приоритете за исключением случаев, наиболее общего пользования. 

Еще одна важная вещь в том, что часто люди будут своего рода попытаться обойти это , говоря, хорошо, так что я сделал сайт, и люди находят, что это заблуждение, и это проблема, не так ли? Очевидно, я не хочу, чтобы люди путать содержанием моего сайта. Но путь к решению, что не иметь что-то выскочит говоря, эй, я собираюсь научить вас, как использовать этот сайт. Шаг 1 - нажмите на эту кнопку. Шаг 2 - идут сюда. Конечно, это способ обойти это - это способ, что вы можете сказать людям, что делать, но это действительно не оптимальным образом. Если я иду на сайт и вдруг я обстреляли с этого учебника, что говорит мне что делать и куда идти, и все, что, это не развлечение для меня. Это не хороший опыт для меня. Это вид боли. Я хочу просто начать делать вещи. Люди собираются, чтобы закрыть их диалоговом окне, или выйти из учебника, не знаю, что делать, а потом жаловаться, потому что вы не сказали им, что делать. Путь к решению это не давая какой-либо учебник или направлениях - что-то в этом роде. Столько, сколько вы можете избежать этого, вы действительно хотите, чтобы показать пользователю, что делать просто по характеру, как веб-сайт выкладывается. Другими словами, если я пойду в Facebook без входа в систему, первое, что я вижу на главной странице - это немного Войти коробка. Так, дух. Я должен войдите Это прямо там. Принимая во внимание, если бы я пошел в Facebook, и мне пришлось нажмите немного ссылку внизу что сказал 'войти' и остальная часть страницы была просто какая-то картинка или что-то, Я бы не знаю, что делать, не так ли? Я бы путать. Так, он может сказать мне, чтобы пойти туда и нажмите кнопку, чтобы войти, или войти в систему кнопку может быть на самом верху, где я собираюсь, чтобы увидеть его. Вы хотите, чтобы всегда показывать пользователю, что делать, и что должно быть присуще самой страницы. 

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

Теперь я собираюсь поговорить немного о том, как управлять проектом веб-разработки. Мы пошли по тому, как вы можете сделать техническую серверную сторону, как вы можете создать действительно хороший сайт, и это здорово, если вы работаете на себя, но - даже если вы работаете на себя, и особенно, если вы работаете в команде, управление проектами становится большой проблемой. Вы вроде слышал об управлении проектами в различных формах с начальная школа, когда вы сказали, групповую работу. Вы должны сотрудничать, общаться, все это. Это все еще применяется здесь, но есть некоторые уникальные обстоятельства с информатика, что вы хотите быть в курсе, и вы хотите, чтобы убедиться, что вы обращаться хорошо. Я поговорю сначала немного о команде, что вы будете дюйма Это очень важно, чтобы выбрать правильный размер команды, чтобы быть работаете, и в вашем окончательном проекте я думаю у вас есть возможность выбрать от 1 до 4 человек, если я правильно. Вы хотите, чтобы убедиться, что вы не просто выбор количество людей что вы хотите работать, потому что они ваши друзья. Вы хотите, чтобы выбрать команду, что это хороший размер, и что будет получить работу. Там в компромисс с наличием большего числа людей против меньшего количества людей. Если у вас есть больше людей, очевидно, больше работы можно сделать потому что у вас много людей, много кода, много идей, и это все здорово. Но это также требует намного больше управление и много больше общения. Другими словами, если у вас есть 4 людей, работающих над одним проектом и они все редактирования и тот же код, более или менее все они вроде должны знать что происходит, так что требует от вас - если добавить некоторые новые функции вы как бы должны сказать людям, - я добавляя, что это, Я меняю это таким образом - особенно если вы получаете в действительно глубокой вещи как моделей и контроллеров, которые на самом деле собираются влиять, как работает сайт. Вся команда должна знать об этом, так что вы должны убедиться, что вы не выбирая слишком большой команды, которая собирается быть трудно чтобы сделать эту связь. Вы также не хотите, чтобы выбрать достаточно небольшую команду, что вы не собираетесь, чтобы быть в состоянии общаться, потому что это только вы. 

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

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

Бен упомянул эту концепцию итерации немного, и я хочу пойти по нему немного. Это действительно важно для работы рывками, где вы получить что-то функциональное. Это может быть хорошо, если у вас есть этот план для веб-сайта, что будет делать A, B, и C, и в конечном итоге это будет попасть. Но вы застряли в этой фазе, где вы работаете на нем и работает на нем, но ничего не становится сделанным. Вы не должны ничего видеть и осязаемое, функциональную вещь. То, что вы действительно хотите сделать, как много, как кажется рода боли иногда работать над чем-то, а затем рода довершение, чтобы он, по крайней мере в стабильной, работает версия даже если он не имеет все необходимые функции. И может быть, есть некоторые особенности, которые вы действительно хотите, чтобы добавить, но вы просто не можете потому что вы хотите, чтобы получить этот сайт в функциональной точки. И поэтому вы хотите отчасти есть весь процесс развития выглядеть. Вы хотите, чтобы с чего-то начать функционально - или, по существу начать ни с чем - но вы хотите получить где-то очень основным и функциональным. И опять же, сделать своего рода прыжок и получить где-то функциональная снова. Вы будете постепенно наращивать, и это могло бы пойти немного медленнее, чем это было бы в противном случае, но в долгосрочной перспективе, если вы постоянно застрял в этой фазе первом, где вы на самом деле не имеет ничего рабочий, это может быть действительно большой разочарование работать над вашим проектом, потому что ты всегда так близко к тому, чтобы он работал, и это никогда не на самом деле работает. Вы хотите работать в этих функциональных рывками, и вы также хотите сделать некоторые размышления после каждой из них. Другими словами, как только вы в точке, где сайт сейчас работает - это не есть все, что нравится, но он делает некоторые вещи - вы хотите думать, ладно, этот сайт достижении цели, что я намеревался сделать? Другими словами, если сайт будет делать X, то, что я работал в направлении X? Все ли функции, которые я хотел там? И более того, это служит общую цель, что я хочу? Если вы считаете, что ваш сайт начинает травить в другом направлении или может быть, все как раз вроде не работают, это может быть время, чтобы переключать передачи немного. Другими словами, это стоит рассматривать - это стоит выбрасывать идеи в случае необходимости и учитывая я действительно работают к тому, что я хочу быть. 

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

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

Последнее, что я буду говорить о некоторых общих передовой практики, и вы видели много таких в CS50, но они также очень, очень применять в условиях проекта. Одним из них является комментариев. Всегда комментировать свой код, особенно если вы работаете на большой команды. Это может быть так раздражает просто гигантский блок кода, который кто-то написал и, возможно, он работает, может быть, это не так, но вы понятия не имеете, что он делает, так что вы понятия не имею, является ли это полезно или нет, или должна ли она быть там или нет, и если вы работаете над чем-то другим, что это даже возможно, что вы работаете на то же самое, так что просто быть очень, очень осторожны, чтобы быть внимательным ваших коллег и написать код, который хорошо документированы. Вы не должны пойти так далеко, чтобы делать все это, где угодно, если вы увеличить Счетчик есть комментарий, который говорит, я добавляю 1 до этого счетчика. Это не обязательно должно быть подробным, но для любой функции, что вы когда-либо писал вы должны иметь документацию о том, что эта функция точно делает, что его входы, и то, что он должен вернуть. Таким образом, вы можете использовать другие компоненты людей о сайте и вы можете работать в направлении создания что-то большое. 

Еще одна важная вещь вы хотите сделать регулярные чистые окна. Код становится грязным. Не расстраивайтесь, если ваш код просто полностью нечитаемым, и гигантский беспорядок. Это происходит в веб-разработке всегда. Ты добавляя новые функции, удаляя старые. Материал будет там, что не должно быть. Это прекрасно, но вы хотите, чтобы убедиться, чтобы иметь дело с этим на регулярной основе. Вы же не хотите, чтобы это построить до точки, где вы просто не можете найти ничего в коде, и вы понятия не имеете, что ни в чем себе. Вот и в случае с HTML. Иногда вы будете в конечном итоге с объектами, которые не содержат ничего, и вы хотите, чтобы избавиться от них. В CSS, вы можете быть относящиеся к элементам, которые не там больше, так что вы хотите, чтобы избавиться от этого кода. В JavaScript, вы можете удалили что-то из HTML. Итак, вы хотите, чтобы убедиться, что вы всегда очистки, что делает вещи довольно столько, сколько вы можете на регулярной основе. 

Еще один очень полезная вещь, что я не думаю, что изложена очень много в CS50 но это стоит того, чтобы в это управление версиями. Идея контроля версий, когда вы в основном отслеживания весь прогресс Вы сделали на ваш сайт, и если в какой-то момент вы понимаете, о, это работает некоторое время назад, но это не работает больше, вы можете вернуться к предыдущим версиям и посмотреть, что изменилось с тех пор и тому подобное. Основной способ сделать это с Git и Git является вся такая система, что Я считаю, Томми MacWilliam провела семинар о в прошлом году. Если вы идете в CS50 семинаров на 2011 год, можно увидеть его семинар по этому вопросу. Идея Git в основном, что на регулярной основе вы делаете эти обязательства которые являются способы сказать сайт находится в довольно стабильной версии прямо сейчас, так Я упаковке его и отправить его прочь к серверу, а затем вы можете пойти на этот сервер и смотреть на все предыдущие версии кода и посмотреть, как он прогрессировал и все такое хороший материал. Так, что в основном это. Насколько веб-разработки, мы рады остаться и ответить на любые вопросы, насколько нашей презентации. Вот и все. Благодаря. >> [Бен] Спасибо. [Аплодисменты] 

[Билли] Персонал, кто-нибудь есть какие-либо вопросы о вещах, которые мы рассмотрели или вещи, которые мы не охваченные, что они надеялись, что мы бы покрыть? Мы были бы рады ответить на них. Любой? [Член аудитории] Каковы плюсы и минусы использования Руби или с помощью Python? [Бен] Вопрос был, каковы плюсы и минусы использования Руби или Python вместо как PHP. Плюсы в том, что Руби и Python намного лучшие языки, чем PHP. По крайней мере, на мой взгляд, и я думаю, во многих чужого мнения, а также. Они были разработаны больше для делать сложные вещи, и меньше для бить вместе веб-страниц очень быстро с немного динамического контента. Минусы в том, что есть немного - есть больше времени на освоение чтобы получить их настроить. То есть, как и в PHP, вы можете просто есть HTML файл, и вы написать меньше, чем, вопросительный знак, а затем вы написать код, а затем вы пишете знак вопроса, больше, чем, а затем вы закончите. В других языках, например Руби или Python, Вы должны пройти немного больше работы, чтобы получить первоначальный сайт работает. Там также - по крайней мере это было так - что есть больше документации доступны для PHP только потому, что есть больше людей, использующих его. Я думаю, что это не столько вопрос больше. Там, безусловно, очень хорошая документация для вещи, как Рубин на рельсы или Django для Python является эквивалентом. PHP является тот, который использует каждый в течение многих лет, и вы знаете, как это работает. Руби и Python являются немного менее зрелые. 

[Член аудитории] Если бы пришлось выбирать между одним из них, чтобы узнать или забрать, что бы вы предпочли? Честно говоря, я думаю, что зависит от человека. Мне очень жаль. Вопрос был, который бы вы выбрали для кого-то учиться? Я считаю, Python самый хороший лично. Есть много людей, которые - я сделал мой первый веб-Dev проект в Python и Django. Есть много людей, которые любят Рубин на рельсы также. Наверное больше людей, которые знают, Рубин на рельсы. Честно говоря, я бы просто пойти с тем, что люди вокруг вас знаю так что у вас есть люди, чтобы задать вопросы. 

Вопрос был - на общих серверах это отчасти трудно работать на Python? Это зависит от вашего хостинга. Есть целый ряд веб-узлов, которые разместим Python вещей. WebFaction делает это, не так ли? WebFaction является одним, что Билли, и я использовал для некоторых проектов. Они действительно здорово. Они поддерживают большинство языков. Но это правда, что PHP является гораздо более широкую поддержку. Так что, если вы застряли на веб-хостинга, что только делает PHP, это хороший повод, чтобы использовать PHP. 

[Аудитория член] Я только что получил в изучение, как запрос к определенным базам данных, и я знаю, что моя SQL является повсеместно, но я недавно получил воздействию - и вы указали на него. Вы видите JSON и расширяемые баз данных. My SQL по-прежнему повсеместно. Как вы видите, что происходит? Есть ли будет растущая тенденция для более расширяемой (неразборчиво)? Вопрос был - я думаю, что это будет тенденция к базам данных не-SQL. Например, как MongoDB. Я думаю, что, безусловно, верно. Мой совет был в основном MySQL, связанных здесь только потому, что MySQL является отраслевым стандартом. Лично я предпочитаю баз данных, которые не имеют schemos как MongoDB где у вас нет проблемы, о, мне нужно добавить еще один столбец. Горе мне, как бы то ни было мне делать? Это очень трудно сделать это на MySQL, но когда у вас есть что-то вроде Монго это намного более хорошо. Другая хорошая вещь о Монго в том, что ваши записи на самом деле объекты JavaScript. Там нет рода стадии конверсии, где вы должны принять эти строки базы данных и превратить их в объект JavaScript, а затем отправить их по сети. Я думаю, что такие вещи, как, что будет очень, очень полезно для быстрого веб-разработки в будущем. 

[Билли] Что-то я хотел бы добавить, что всего лишь общие Дело в том, что не чувствуете, как вы должны были узнать все языки, которые мы обсуждали от нашего семинара. Очевидно, дело в том, чтобы дать вам представление о том, что там, и если вы заинтригованы любой из вещей, которые мы упомянули, что вы можете Google их и прочитать о них. И как я уже говорил, есть несколько семинаров, которые имеют дело именно с этими вещами. Есть даже больше семинаров, которые я не упомянул, что, вероятно, попасть в этот материал также. Идея состоит в том, что, если вы хотите работать над чем-то, вот инструменты в вашем распоряжении. Не чувствуют себя подавленными, если вы не совсем уверены, что эти инструменты делают точно, но знаю, что они там и что вы можете сделать широкое применение из них на Google. 

[Член аудитории] Какие вещи вы должны сделать, чтобы убедиться, что ваш сайт хорошо выглядит на мобильных устройствах? [Билли] Мобильные устройства немного трудно. Там в 2 способа вы можете подойти к нему. Первый способ является то, что у вас действительно есть мобильный веб-сайт. Другими словами, необходимо выполнить какую-то обнаружения в начале когда браузер делает запрос на ваш сайт, которые либо говорит вернуть этот вид - который станет представление для настольных или портативных браузеров - и этот другой вид для мобильных устройств. Это место, где взгляды действительно хороши тем, что вы можете очень многое подкачки два и иметь интерфейс, который работает очень хорошо на мобильных устройствах и иметь совершенно другой, который работает хорошо на устройствах браузера. Проблема в том, что занимает много времени, потому что это означает кодирование совершенно другой интерфейс. Другой способ, что вы можете сделать это является - много современных телефонов будет отображать сайты и попытаться сделать их как браузер будет, и они делают все возможное. Вы можете рода попытаться остаться свет от количества JQuery JavaScript вы используете который имеет тенденцию быть, где вещи могут пойти не так немного. Это своего рода таким образом, что вы должны использовать, если вы не так уж много времени. Если у вас есть время для работы на мобильном интерфейсе, это, очевидно, лучший выбор. 

Я думаю, что в целом для CS50 проектов, вы собираетесь хотите, чтобы выбрать один или другой. Другими словами, вы хотите, чтобы сделать мобильное приложение или вы хотите сделать сайт на рабочем столе. И такого рода определяет, где вы идете с этим. Но если вы хотите, чтобы развернуть его позже, вероятно, вам лучше всего сделать еще один интерфейс для другого. У меня есть немного опыта в разработке сайтов WordPress-приложений. Я прошел личный сайт на WordPress на некоторое время. Те виды рамок может быть хорошие как очень простые вещи. Часто вы будете просто столкнуться с большим количеством проблем Customizability же. Вы хотите, чтобы иметь что-то выглядеть определенным образом или быть определенным образом и вы просто не можете, потому что это зашитыми в систему, которая это, как вы должны делать вещи, которые могут быть чем-то вроде проблемы. С тех пор я отчасти было более склонны работать с сайтов с нуля. Для таких вещей, как блог баз данных и такого рода вещи это действительно не так уж трудно построить основу. Если вы действительно растягивается на время, вы можете, конечно, использовать что-то вроде WordPress или тому подобное для блога. Те вещи, что блоги магазин и делать на самом деле не достаточно сильно, что если вы работаете в любой из этих видов вещей, вы, вероятно, лучше просто сделать версию в доме. 

Я думаю, что это о нем, поэтому еще раз спасибо, что пришли. Мы действительно любили говорить с вами, ребята и надеемся, что вы узнали некоторые вещи. [Бен] Мы рады поговорить - мы должны идти, но мы рады говорить больше за пределами если у вас есть еще один вопрос. Еще раз спасибо. [Аплодисменты] [CS50.TV]