[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]