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