[Powered by Google Translate] [Seminari] [Desenvolupament web: De la idea a l'Aplicació] [Ben Kuhn] [Billy Janitsch] [Universitat de Harvard] [Aquest és CS50] [CS50.TV] [Billy] Hola, sóc Billy i això és Ben. >> [Ben] Hola. Estarem parlant de desenvolupament web avui en dia. [Webdev] [Billy Janitsch i Ben Kuhn] Una mica sobre nosaltres primer. Ben és una espècie de tipus de fons. Ell fa que les coses funcionin. I llavors vaig i els faig bastant. Estic en gran mesura involucrar-se amb més front-end de disseny de disseny tipus de coses, i Ben, per la seva banda, sap el que està fent pel que treballa en la matèria de fons. Junts hem fet un parell de coses. Per exemple, l'any passat es va treballar en Gimblium que és un estudi de desenvolupament de jocs en línia. Aquest va ser el nostre últim projecte per a la classe, i des de llavors ens hem fet la classe de Harvard que és un marc per a la navegació en línia i cursos comercials a Harvard. 

Anem a començar amb aquesta idea per al nostre lloc web. Farem això, però per als gats. Abans que realment fer d'aquest lloc web, no fer d'aquest lloc web, ja que no és bo, però utilitzarem com a marc i passar pel procés de com es pren aquesta idea i convertir-lo en un lloc web real que podem utilitzar. Anem a començar per trencar el lloc web de sota. Igual que ha estat fent en el CS50, vostè vol pensar sobre quins són els components reals que van en aquest lloc web. Bàsicament convertint d'una idea que és només una espècie d'un concepte abstracte en una cosa real i tangible que vostè podria fer. Comencem a fer algunes preguntes. Què és aquest lloc? Per què estem fent això? Què es va a utilitzar per? Aquest tipus de coses. En el cas de Facebook Cat, que, bàsicament, volem un lloc web que permet als gats xarxa social amb els altres. La idea és que es poden publicar a les parets de cada un, poden fer comentaris, aquest tipus de coses. I aquí és on entrem en els components funcionals. Ara tenim aquest tipus de marc de - comptem amb els perfils d'usuari, tenim comentaris, i podem publicar. Potser algun dia anem a influent gustos i aquest tipus de coses. I quin tipus de volem prioritzar aquestes característiques va in Volem dir com, bé, és molt important que tothom té un perfil i que tothom pot escriure a les parets dels altres. Secundari a aquests comentaris serien agradables. Potser més endavant anem a influent gustos. Així doncs, vostè vol tenir una idea del que és fonamental per al seu projecte i el que és una espècie de tret més general que podria aplicar-se més endavant. Vostè voler espècie de tenir una llista específica en ment, però el projecte que comenci a treballar no serà el projecte que acabi amb. En altres paraules, les coses canviaran quan s'està creant el lloc, i vol deixar espai per això. Vaig a donar-li la volta a Ben qui va a parlar una mica sobre l'estructura. 

[Ben] jo vaig a estar parlant de la part més tècnica de desenvolupament web. Anem a repassar alguns conceptes bàsics en primer lloc. Quan estàs fent una aplicació web, la divisió principal que hauràs de tenir és vostè va a tenir una mica de coses que estan passant al costat del client - és a dir, el codi que estàs navegador porta des del lloc i el JavaScript, HTML, CSS coses. Això és tot en el costat del client. Vostè va a tenir un altre tipus de codi que s'executa en el costat del servidor que realitza un seguiment de totes les dades que la gent envia a vostè, decideix a qui donar-li el que, coses així. Això és només una mica de terminologia perquè vostès estan familiaritzats amb el que estem parlant. Més enllà d'aquesta divisió és bo pensar en la seva aplicació web en termes de un parell de components diferents. Quan vostè està fent desenvolupament web una de les coses que vostè sempre ha d'estar intentant fer és reduir la complexitat. Com més complex sigui el codi és, més possibilitats hi ha de fer errors, més difícil és canviar més tard. Per tant, si vostè pot trencar la seva aplicació en algunes àrees funcionals diferents que farà - i vostè pot reduir la quantitat d'espècie de comunicació entre l'àrea - que l'ajudarà molt en el llarg termini en termes de reducció d'errors. 

Per ser concrets, en general les persones divideixen una aplicació web en - aquests són una mena de paraules de moda ara, però segueixen sent útils. És possible que hagi sentit parlar dels models, vistes i controladors. Els models són les dades reals que la seva aplicació es va a tractar. Per exemple, si gat Facebook, els seus models serien - vostè tindria un model per als missatges, com, i un model per als perfils d'usuari, coses per l'estil. Els seus punts de vista són la targeta de presentació de les dades als usuaris. És possible que tingui 1 vista per mirar a un sol lloc i tots els comentaris i una visió diferent per la seva paret que té una llista de tots els missatges que es dirigeixen a vostè, i una visió diferent del seu servei de notícies - coses com aquestes. Finalment, vostè té els controladors que són, bàsicament, quan la gent t'envia missatges i vostè fa canvis al seu sistema de back-end, incrementes un munt de comptadors, i el que sigui. Aquests són els controladors. 

Vaig a parlar sobre tot sobre els models. Vistes tècnicament no són tan difícils i el problema és més amb el disseny d'ells Controladors seran específics del que sigui que vostè està dissenyant. Però hi ha algunes tècniques molt generals que es poden utilitzar per fer les seves models més agradable i més fàcil de treballar que crec que són molt útils. Això és sobretot serà sobre com tractar amb les seves dades d'aplicacions web d'una manera agradable. Els principals problemes amb els models hi vivien en el client i el servidor i has de esbrinar a) la forma d'aconseguir-los - tots els rellevants - des del servidor al client, ib) la forma de mantenir-sincronitzats. Els seus usuaris voldran fer alguns canvis. Ells voldran fer nous llocs. Ells voldran que fossin les coses i aquestes coses si tens gustos. Aquests són els principals desafiaments tècnics de tractar amb models. La primera cosa que vostè va a voler preguntar-se és quin tipus de dades va en aquest model i quin tipus de consultes voldrem fer - és a dir, com anem a mirar els models? Per a la seva gat Facebook exemple, el seu missatge tindrà un autor associat a ell, algun text publicació al mur, i un receptor de la publicació en el mur. I llavors molts de vosaltres voleu per consultar que en un munt de diferents maneres. Vostè vol veure-ho per qui va escriure que després, per qui va rebre el de publicar, potser per la data en què van ser publicades. Però si vas a fer-ho per data, llavors vostè ha de afegir un altre camp al teu lloc quan en realitat va ser publicat. Aquests 2 factors - el que les dades que voleu utilitzar i com desitja per veure-la - cal pensar en ells en primer lloc, ja que depenen els uns dels altres, i que serà més difícil afegir més endavant. 

Hi ha algunes altres consideracions. Quan vostè està pensant en com fer front als models al servidor el que vol veure és - que, bàsicament, vol fer que el servidor el més simple possible. Fer coses en el costat del client és generalment molt més ràpid si vostè pot fer-ho únicament en el client sense fer cap tipus de sol · licitud de xarxa. La idea és fer la major quantitat de consultes com puguis en el client. L'únic problema amb això és que si vostè demana totes les dades en l'inici llavors això va a trigar molt de temps a carregar. Per tant, la idea és trobar un terme mig entre tenir suficients dades en el client que vostè pot fer la major part del seu treball allà, però no només anar a buscar tot alhora perquè vostè obtingui els temps de càrrega molt lenta al principi. Per exemple, per a les dades de gat vostè probablement voldrà portar un munt de publicacions en el mur recents. No vol a cercar a tots, perquè això podria tornar un parell d'anys. Però no vol a buscar un a la vegada perquè això seria introduir una gran quantitat de sobrecàrrega de la xarxa. 

Sovint és molt difícil - una vegada que vostè té una base de dades en execució - que és sovint molt difícil canviar les dades que tens a ell - és a dir, afegir una columna de base de dades nou o alguna cosa - pel que una bona estratègia és en realitat només per mantenir una gran quantitat de dades en una bombolla de text - una taca JSON - JSON sent JavaScript Object Notation - La raó que és útil és perquè llavors vostè pot afegir noves propietats a totes aquestes taques JSON sense canviar la seva base de dades. L'únic desavantatge d'això és que si vostè té un munt de camps que ha afegit més tard - com amagat en aquesta bombolla JSON - llavors és més difícil de consultar a l'interior la base de dades. Per exemple, si més endavant - si vostè tenia el seu model post que hem comentat anteriorment amb només l'autor, el destinatari i el text - vostè també podria tenir una taca JSON i després si més endavant voleu afegir un camp de data vostè no ha de canviar la seva base de dades. Es podia afegir dates a tots els camps de text. I llavors seria capaç de mirar als del costat del client, però no seria capaç de consultar-los en el costat del servidor perquè està amagat dins d'aquest text. 

L'altre tema que vostè vol pensar en és com el seu client i el servidor es va a comunicar. Generalment, vol mantenir això tan simple com sigui possible. Vostè només pot tenir com una-em-get aquesta sol · licitud de dades, 1 crear un nou objecte-cosa, i una sol · licitud d'actualització-an-old-objecte. I aquests serien tots diferents adreces URL al servidor que vostè - que el navegador seria - es pot utilitzar peticions AJAX per a tots ells i rebre o enviar dades. Una vegada més, per al nostre gat Facebook exemple, vostè podria haver de URL per obtenir una entrada individual, i vostè tindria una URL per crear una nova publicació al mur i potser un URL per pujar la teva foto de perfil, coses així. Però, de nou, això és precarregar la major part de les seves dades perquè vostè no ha de mantenir fer sol · licituds de xarxa. Per aquesta raó, és possible que no vull tenir aquesta petició get individual per a un sol lloc, i en lloc que vostè només vol 1 petició d'obtenció de tota la paret. I llavors, si vostè està tractant de trobar un equilibri, perquè - això també dependrà de la seva aplicació. Perquè si vostè està esperant que la gent només té 10 o 20 publicacions en el mur que estarà bé. Però si esperes que tindran milers llavors aquesta sol · licitud seria massa llarg, i així és possible que vulgueu afegir un paràmetre get-tots-posts-des de llavors. 

Per tot això vostè està probablement va a voler sincronitzar les seves dades en JSON - JavaScript Object Notation. Gairebé tots els llenguatges s'ocupa de JSON molt bé. JQuery té aquesta bonica funció getJSON que farà tot el treball dur per vostè. I en PHP també hi ha funcions de comunicació JSON molt agradables. Llavors, això és, probablement, el millor format per a l'enviament dels seus models d'anada i tornada. 

Com a exemple del que hem parlat fins ara, vet aquí un exemple de flux per al seu gat aplicació de Facebook. Comença amb l'explorador que demana la URL del lloc web base. El servidor probablement seria enviar a través d'HTML estàtic i una mica de JavaScript i CSS. En general és millor no fer cap representació al servidor. És probable que no vol - el que el servidor no està fent allà va per la llista de publicacions en el mur i generar una mica d'HTML per a cada un i l'enviament que més. En general és la millor manera de fer això al costat del client perquè si cada vegada que vulgui tornar a dibuixar alguna cosa, vostè ha de fer una sol · licitud del servidor. I això molt ràpidament li dóna un munt de despeses. En general és millor només per la nau ha fet baixar estàtica HTML i després JavaScript i CSS que faran la prestació per part del client. Així que això entra, llavors vostè pot tenir - en JavaScript - vostè pot fer les sol · licituds per a les dades paret i coses per l'estil, i després que el servidor està bàsicament fent consultes de bases de dades i la comprovació de permisos. L'única cosa important és que no es pot enviar a través d'altres publicacions en el mur usuaris que vostè no està autoritzat a veure. Bàsicament pot ser una capa molt prima d'accés a la base de dades, i després, de la qual mostren les dades - tots els punts de vista i aquestes coses - els que poden succeir al navegador, i després quan es vol fer un post o alguna cosa que acaba d'enviar una nova sol · licitud. 

També hi ha algunes coses de luxe que es pot fer a la part superior d'aquesta. Quant a la informació tècnica més específica, desenvolupament en la plana JavaScript pot ser una mica dolorós, així que hi ha algunes biblioteques i eines que l'ajudaran molt amb això. Crec que tots hem sentit probablement sobre jQuery que fa fer el processament d'HTML i la manipulació molt més fàcil - tenen un munt de funcions de luxe per a la decoloració d'entrada i sortida, i fer animacions ZIPPY. També hi ha aquesta biblioteca anomenada Underscore.js. Té una gran quantitat de funcions d'utilitat útils, coses que es pot esperar a tenir JavaScript que realment doesnt - coses com estudiar una matriu, l'eliminació de duplicats d'una llista, o aplanar una llista de llistes. Això és només un petit exemple de codi. Subratllat té una tona d'aquests simpàtics funcions que vostè desitja que tindria tot el temps. 

I després hi ha l'1 biblioteca més que m'agradaria passar una mica de temps en anomenat Backbone.js perquè Backbone realment ajuda a lluitar amb models al costat del client i una gran part de la confusió que pot causar. Backbone li dóna aquest concepte de models i col · leccions en JavaScript que són, bàsicament, exactament igual que els objectes JavaScript en matrius de JavaScript, però tenen esdeveniments a canviar les seves propietats. Igual que en JavaScript, pot fer que un esdeveniment quan es fa clic a un botó o alguna cosa aquests models de Backbone i col · leccions Backbone transmetran coses com que quan canvien. Això vol dir que vostè pot escriure alguna cosa com aquest fragment de codi aquí - això diu, sempre que s'afegeixi res a la matriu missatges redibuixar tota la paret. I això deia sempre que el nombre d'un lloc de talla canvia, vostè notifiqui a l'usuari que algú li agrada el seu lloc. O cada vegada que qualsevol propietat d'un lloc canvia redibuixar el lloc. Coses com que li estalviarà tones de complexitat perquè en cas contrari si vostè no té algun tipus de marc com aquest, llavors cada vegada que en el codi que canviï res sobre un post, que hauria de recordar-se a si mateix que cridar a totes les funcions de render i coses per l'estil, i si volia afegir alguna cosa nova que va succeir cada vegada que es va modificar un lloc que hauria d'anar a través de cada lloc en el seu codi que ha modificat un post i afegir aquesta cosa nova. Un marc com aquest eliminarà un munt que la comunicació entre capes que fa el codi complex i difícil de mantenir. 

Hi ha una mica de vistes també. Vaig a deixar la major part d'això a Billy perquè tècnicament no són molt difícils. Utilitza jQuery per als seus punts de vista. És pràcticament com una necessitat en aquest punt. Simplement fa que tot sigui molt més fàcil. Hi ha una gran quantitat de biblioteques. Si s'ha complicat els elements d'interfície d'usuari, si vols alguna cosa d'auto-completar o com un d'aquests elegants múltiples selectors - si vols alguna cosa així, probablement hauria simplement buscar al voltant i es pot trobar una bona biblioteca que farà el que vols. Billy li explicarà més sobre les parts realment difícils de visites. A més, com a nota al marge, Backbone té algunes funcions per fer visites comuniquen molt bé amb els models - miri la documentació de totes aquestes biblioteques, en realitat. Només cal mirar als docs. Estan molt ben escrit i fàcil de seguir. En general, es pot pràcticament només Google si té problemes. Hi ha una gran quantitat de persones que els utilitzen. Crec que això és com una nota al final. 

També hi ha algunes coses més avançades que vostè pot fer si vostè està buscant per fer la seva aplicació web extra impressionant. Vostè pot fer - la nova especificació HTML5 té un munt de coses de luxe que vostè pot fer. Emmagatzematge local - que és que pot emmagatzemar dades en el navegador - en lloc d'haver de tornar enrere i llegir el servidor per a tot, vostè pot mantenir una mica d'ella en el client i que fins i tot permet a la gent - en alguns casos fins i tot pot permetre la utilització de la pàgina web fora de línia. Hi ha una cosa que es diu WebSockets que són un tipus diferent de la comunicació en xarxa on en comptes de vostè fa una comanda, s'obté la resposta i ja està, segueixes obrir una connexió amb el servidor i pel que pot fer coses com actualitzacions en temps real. Així que, si estàs tractant de fer una aplicació de xat, podeu utilitzar WebSockets per comunicar amunt i avall de manera que vostè no hauria de seguir demanant, "Oh, servidor, algú m'envia un xat?" cada 10 segons o alguna cosa així. També hi ha una característica interessant HTML5 on es pot fer que sembli que l'adreça URL de la pàgina està canviant sense haver de recarregar realment. Podeu utilitzar els botons Enrere i endavant sense fer un munt de peticions de xarxa. Coses com aquesta és molt útil en termes del que és ràpid però també funciona com una aplicació web hauria. 

També hi ha una cosa anomenada CoffeeScript. CoffeeScript és un llenguatge diferent, en realitat, que compila a JavaScript. Es podria escriure tot el codi en CoffeeScript, i després executar aquest compilador, i escup un arxiu JavaScript que es pot incloure a la teva pàgina web. La raó que CoffeeScript és bo és perquè es desfà d'una gran part del casos estranys que el JavaScript on iguala iguals, i és igual als iguals fan coses diferents, o els agrada - té millor sintaxi per fer front a les matrius i funcions. Aquest és un petit fragment de CoffeeScript que genera una llista de totes les places de 10 ^ 2 a 1 ^ 2 en ordre invers. Com podeu veure, CoffeeScript sovint li permet expressar en 1 línia el que portaria 5 línies de JavaScript. Es pot fer les coses molt més fàcil. És una mica de la nova sintaxi d'aprendre al principi, però sens dubte et farà més productiu en el llarg termini. 

També podeu utilitzar altres idiomes al servidor i PHP - llenguatges com Ruby, Python, o fins i tot hi ha un projecte anomenat Node.js que li permet utilitzar JavaScript al servidor. Personalment, jo realment, realment odi PHP. És només que no gaudeixo de treballar amb ell. Si vostè també pensa que es tracta d'un cluge horrible d'una llengua, llavors vostè pot utilitzar un d'aquests al seu lloc. En general, si vostè vol fer alguna cosa i no sap molt bé com ho faria, simplement buscar a Internet. Hi ha tones i tones de recursos, especialment en - StackOverflow és un gran. És aquest lloc web on els programadors es fan preguntes. És possible que s'han topat amb ell si estàs tenint problemes en els butlletins de problemes CS50. I hi ha un munt de biblioteques per fer gairebé qualsevol cosa que vulguis. Si vostè vol fer alguna cosa i no saps com fer-ho, no assumeixi que és impossible. Només cal mirar al voltant i vostè pot trobar alguns bons recursos. 

Com general acabar, els principals robatoris de pilota són mantenir les coses simples. Com més complex sigui el codi està al principi i com més es tracta de fer coses de luxe, com més temps es trigarà a aconseguir alguna cosa realment funcional i més difícil serà canviar més tard. Per tant, fer les coses de la manera ximple, fàcil primer. Per anar juntament amb això, no tinguis por de tirar codi antic o netejar molt. En general, una vegada que realment té una mica de treball, és molt més fàcil pensar que quan encara està en els primers passos de com puc posar tot això junt. El millor és fer que el més ximple possible disseny que funciona i després millorar iterativa de tractar de fer tot bé la primera vegada. Quant a la divisió de client-servidor, tractar de mantenir el seu servidor molt simple - només una base de dades i una mica d'autenticació i no fan cap treball dur allà. Tots teves coses complicades al client en el navegador en JavaScript com tot el que pugui. Miri al seu voltant per a les biblioteques que fan la seva vida millor. Sempre és millor fer servir el codi que algú més va escriure si vostè - i no ho escriguis tu mateix. Hi ha un munt de coses a Internet. Google és el teu millor amic. Google és el millor amic del programador. Sí, definitivament, no tinguis por de mirar al seu voltant per la matèria. Està bé. I a Billy. 

[Billy] En realitat, abans de començar amb una mica de matèria de disseny, Algú té alguna pregunta per a Ben sobre qualsevol cosa que ell va parlar de? D'acord, bé. Un cop més, sabrem si alguna cosa no està clar o si voleu que anem per alguna cosa una mica més. Vaig a retrocedir una mica i parlar de les parts més fonamentals del disseny. Ben va esmentar el model anomenat - ho sento, el sistema Model View Controller que és una espècie de la part tècnica, així que vaig a veure punts de vista en concret, i jo vaig a començar amb com li agradaria dissenyar una vista que es veu bé. Aquí hi ha una mena de plantilla realment bàsic per al nostre gat Facebook. Crec que hi ha alguns aspectes fonamentals en el disseny d'interfície d'usuari moderna que val la pena recollir. Vostè pot notar que hi ha un munt d'espai en blanc per tota la pàgina, molt espai per a les coses. No senti que ha de aixafar coses en una pàgina. Vols deixar un munt d'espai obert, i si vas a gairebé qualsevol lloc web modern veuràs que hi ha blanc per tot arreu. No hi ha blanc en llocs que no es poden esperar. Vostè té aquesta paleta de colors, i és savi al principi triar una paleta de colors que va a treballar i desenvolupar-se. També - Ajuda a triar un tipus de lletra, i d'aquesta manera et tipus de treball amb aquests fonaments concrets de disseny. Vostè té el seu tipus, té els seus colors, i llavors vostè pot tipus de posar tota la resta en el que necessiten. Així que, com he dit, amb el seu esquema de color que voleu utilitzar els colors més atrevits del seu esquema de color moderació. Encapçalats són agradables. Els botons són bo tenir realment grans, colors cridaners. Però en general, si vostè té un lloc web que té colors per tot arreu, tot el que salta a la vista, que només es veu desordenat, i no és bo. Voleu utilitzar generalment de colors clars. Proveu de nou, triar un esquema de color molt coherent. Vostè pot tenir aquestes petites pinzellades de molt color - que pot semblar bastant agradable, però desitja utilitzar molt escassament. 

Com ja he dit, vol ser mínim. Menys és gairebé sempre més. Si vostè pot mostrar alguna cosa o no mostrar alguna cosa, i ets una mica segur de si hauria d'estar aquí per defecte - probablement estàs millor deixar-lo fora. Sempre es pot afegir més tard. Sí, mantenir les coses simples. Però el més important, vol considerar múltiples dissenys. No pensis que quan vostè fa un lloc, ho tens al teu cap que et fer que el lloc d'una manera determinada, i que serà exactament així. Va a tenir la capçalera blava a la part superior i la barra lateral blava i llavors la cosa sub-encapçalat groc. Vols fer diverses plantilles. Vostè pot - si ets bo amb Photo Shop, pot obrir això i tipus de dissenyar un lloc web que vulguis que es vegi. Si no, pot simplement usar la ploma i el paper, però ratllar múltiples dissenys. Vols tenir bàsicament un sistema per dalt on vostè té un munt de diferents dissenys, i si un acaba treballant, llavors això és genial. Si un acaba fallant, llavors un sempre té un altre a qui recórrer. En general, no se sent com que sigui constret a qualsevol disseny que en un inici es decideixi sobre. Els dissenys són molt variables, i part de la importància del model vista controlador del sistema és que es pot canviar i sortir de diferents punts de vista que desitgi. Pot influir en les dades d'una manera, i després decidir, oh, realment, que no funciona tan bé. Crec que és una cosa massa complicat o hi ha una part aquí que no està realment treballant, així que només vaig a abandonar totalment aquest punt de vista i d'intercanvi d'una forma totalment nova. Encara podem usar els vells models i els vells controladors. Podem fer tot el que en el servidor i el client com ho faríem abans. Però l'onada actual de les dades mentre es mostra serà una mica diferent. 

Pel que fa a l'aplicació real el disseny que desitgi, un cop alguns dissenys esbossats en paper oa la botiga de fotos o el que sigui, hi ha una sèrie d'eines que estan disponibles per a vostè. El primer vostè està molt familiaritzat amb la qual és la seva HTML, PHP, o el que sigui idioma que està fent servir només per a codificar les pàgines estàtiques al seu lloc web. Vostè ha treballat molt amb HTML quin tipus de li dóna les següents etiquetes que pot posar les coses en, i, bàsicament, és una forma d'organitzar el contingut. Per exemple, vostè té la capçalera fins allà, així que vas a tenir una etiqueta de capçalera, i que tindrà una mica de text dins de la mateixa que és, probablement, serà en una altra etiqueta. Llavors vostè té una barra lateral potser amb alguns enllaços diferents, i els que van a estar tots a separar les etiquetes. Així que, bàsicament HTML en el seu cor és una manera de dividir la pàgina com finalment desitja formatar. Així que de nou, has vist això abans. Ets bastant còmode amb el treball amb ell ara considerant que s'ha fet l'últim conjunt de processadors amb sort, per la qual cosa hauria d'haver cap problema. 

Llavors vostè ha CSS que bàsicament s'encarrega de tots els aspectes estàtics de disseny. Seria gestionar tots els colors, tot el posicionament dels diferents elements, on van amb respecte a l'altra, el grans que són, els diferents tipus de posicionaments que vostè hauria - en altres paraules, pot haver coses fixa de manera que quan es desplaça cap avall es queden, o pot fer que les coses en relació amb altres elements. Tot aquest tipus de coses és en el CSS. A més, vostè pot fer decoracions diferents, pot fer que els colors del text, efectes de text, tot aquest tipus de coses. Ben va donar un molt bon seminari sobre aquest passat cap de setmana, i així que sens dubte comprovar que fos si estarà fent algunes coses de luxe amb CSS. CSS3 és en realitat l'última versió de CSS, i es pot fer tot tipus de coses realment agradables. Es pot fer gradients, vostè pot tenir agradables, cantonades arrodonides, es pot fer tot tipus de coses per fer el seu lloc web un aspecte més modern i elegant. 

La següent eina és JavaScript i jQuery que Ben va parlar una mica sobre, però Vaig a buscar una mica més en. JavaScript, ja que ha treballat amb ell una mica, o almenys vist a classe, és una espècie de forma de fer les coses de forma dinàmica en HTML. HTML, com vostès saben, és estàtic, de manera que una vegada que tingui HTML no pot modificar-lo. Però JavaScript en certa manera, és una manera de ser capaç de modificar l'HTML. Així que vostè pot fer això, i això és genial, però Javascript és realment un mal de treballar. És tan llarg i obtús i per fer les coses més simples requereix una gran quantitat de línies de JavaScript. Així, jQuery és bàsicament una llibreria JavaScript que simplifica tot això. Es diu, està bé, si vostè vol tenir una caixa quadrada venir de l'esquerra i s'esvaeixen en la pàgina de manera que està al mig, en JavaScript que prendria - No sé, un centenar de línies per fer, i seria un mal, i se surt d'ell odia tot el relacionat amb la programació web. JQuery que, bàsicament, té l'element-punt-fade-in, o alguna cosa així. Funcions tant, molt, molt senzills que li permetrà fer tot tipus d'animacions fresc i aquest tipus de coses. L'altra cosa que aquests 2 són molt bons per només està fent coses dinàmiques amb el lloc web. Així, en lloc de tenir la seva pàgina HTML - que mostra algunes dades, però que en realitat no fer res - JavaScript i jQuery li permetrà tenir botons que vostè pot fer clic a, i vostè pot arrossegar elements i Reordenar i ordenar-los, i tenen nous elements afegit o eliminat. Vostè pot afegir-delete, aquest tipus de coses. Així, jQuery fa un munt de coses interessants. I Vipul està realment donant un seminari a ell avui, crec, a les 5 en punt, així que si vostè pot quedar-se per tant de temps, que ho faria - 5 o 4? Quatre. Ho sento. De fet, és just després d'això, pel que recomano enganxar voltant per si pots. JQuery és super, super útil, i vostè serà capaç de fer un munt de coses realment agradables amb ella per a gairebé qualsevol projecte de desenvolupament web. 

Ara vaig a entrar en una mena de distinció. He estat parlant bàsicament sobre la interfície d'usuari. La interfície d'usuari és només el disseny del lloc. Però hi ha una espècie d'un altre concepte que és l'experiència de l'usuari. Tots dos són molt diferents. La interfície és sens dubte part de l'experiència. En altres paraules, quan vostè va a un lloc, ens fixem en la interfície. Això és part de la forma d'experimentar el lloc. Però l'experiència d'usuari és més que això. L'experiència de l'usuari és sobre el que la impressió que l'usuari rep del seu lloc és. Així que, òbviament, la interfície és una part d'això. I és definitivament una part necessària, però no és suficient. En altres paraules, si teniu una interfície agradable, i és bonic i colorit i tot això, això és genial, però si l'usuari va al seu lloc, es veu un disseny bonic i està confós per tot, no té idea de com fer alguna cosa, llavors, evidentment, vostè ha fet una realitat pobres lloc web. En certa manera és on entra en joc l'experiència de l'usuari Vaig a parlar una mica sobre el disseny UX - UX és l'abreviatura de l'experiència de l'usuari - i una mena de com vostè pot assegurar-se que vostè té una bona experiència d'usuari. El primer punt és que vostè pot dissenyar un lloc web on l'usuari pot fer qualsevol cosa que que l'usuari possiblement vol. Però si l'usuari no pot trobar la manera de fer les coses - en altres paraules, si l'usuari no té una bona idea quan van al seu lloc de, "Oh, si vull actualitzar el meu perfil, i després fer clic en aquest botó, o si vull escriure al el mur d'algú, llavors jo vaig al seu tauler i feu clic a una capseta ". Si l'usuari no sap això, llavors vostè efectivament té en realitat no implementat aquesta funcionalitat correctament. Una part de la implementació d'una funcionalitat és que els usuaris són realment capaços d'utilitzar. I pot ser frustrant - vostè podria fer un lloc, i es pot fer tot tipus de coses meravelloses, però llavors tindràs gent prova i diuen: "No puc fer això. Per què no pot fer això? "I li dirà a ells, "Bé, pot. Només has d'entrar al menú desplegable setè en aquesta fosca pàgina que només es troba en un enllaç a la part inferior dreta "o alguna cosa així. Òbviament, vostè no vol això. Vostè vol que sigui clar als seus usuaris el que se suposa que han de fer, i que ha de ser simple i intuïtiu per a ells. 

Una altra cosa que vostè vol tractar de fer és, si algú va a anar al seu lloc i 9 de cada 10 vegades fan l'acció A, i 1 de cada 10 vegades fan l'acció B, és probable que vulgui enfocar la seva experiència en l'acció A. En altres paraules, vostè vol que sigui molt, molt clar com fer-ho A. Una ha de ser de primera i de centre - anar al lloc, veure-ho, oh, està just allà. Atès que el B, òbviament, vol que quedi clar, però vostè pot deixar una mica més en el fons. David dóna un bon exemple d'això en la conferència, que és el sistema de Boston T. Quan vas a la Boston T i vostè vol comprar un bitllet, vostè ha d'entrar en 5 menús abans que realment pot comprar un bitllet per un valor de $ 2, $ 2.50, que és la quantitat que es necessita per viatjar al metro en una direcció. Això és un problema perquè la majoria de la gent que està al metro Probablement només vol anar a un lloc, comprar el seu bitllet, obtenir en forma immediata. No té sentit que han de passar per un munt de diferents menús per arribar-hi. Una millor experiència de l'usuari seria un botó d'accés ràpid a la primera pàgina que simplement diu, "comprar un bitllet d'anada", i això posaria en tota la norma valors per defecte, i després, si algú vol comprar un bitllet diferent que, encara, per descomptat, tenen l'opció, però que ha optimitzat per el cas d'ús comú que és realment important. Pots veure exemples d'això a Facebook, no? Si vas a Facebook i voleu publicar un estat, que està just a la part superior que és el que sovint vol fer. Tan aviat com entres a la pàgina, pot fer les coses més comunes que que vols fer. Si vostè vol fer les coses una mica més complicades com, dic que vull anar a la paret del meu amic i posar una foto en ell - que vaig a voler fer sovint, però no tan sovint com la publicació d'actualitzacions d'estat - pel que en aquest cas, escric el seu nom al quadre a la part superior, feu clic en el seu perfil, i després, encara, està just a la part superior hi ha una vegada que m'he ficat al seu perfil. Un cop més, he optimitzat en prioritat per als casos d'ús comú més. 

Una altra cosa important és que sovint la gent espècie de tractar d'aconseguir al voltant d'aquest dient, està bé, així que he fet el lloc i la gent els resulta confús, i això és un problema, oi? Òbviament, jo no vull que la gent es confonen pel contingut del meu lloc. Però la forma de resoldre aquest no és tenir alguna cosa pop-up dient: bé, jo et vaig a ensenyar com utilitzar aquest lloc. Pas 1 - feu clic a aquest botó. Pas 2 - feu clic aquí. És clar, això és una manera voltant d'ella - és una manera que vostè pot dir-li a la gent què fer, però és Realment no és la manera òptima. Si vaig a un lloc web i de sobte em bombardegen amb aquest tutorial que m'està dient què fer i on anar i tot això, això no és divertit per a mi. No és una bona experiència per a mi. És una espècie de dolor. Vull començar simplement fent coses. La gent va a tancar fora del seu quadre de diàleg, o sortir del programa d'aprenentatge, no sap què fer i, a continuació, es queixen perquè no els ha dit què fer. La manera de resoldre això no és donar cap tipus de tutorial o adreces - res d'això. Per molt que es pot evitar, que realment vol mostrar a l'usuari què fer només per la naturalesa de com el lloc web es presenta. En altres paraules, si vaig a Facebook sense necessitat d'accedir, el primer que veig a la pàgina principal - és una petita caixa de connexió. Així, duh. He d'entrar Està just allà. Atès que, si jo vaig anar a Facebook i que havia de fer clic en un enllaç mica a la part inferior que deia 'connectar' i la resta de la pàgina era només una mena de quadre o alguna cosa, Realment no ho sé què fer, oi? Jo estaria confós. Així, podria dir-me d'anar allà baix i feu clic al botó per iniciar la sessió, o el botó Inicia sessió podria ser la dreta a la part superior on vaig a veure-ho. Vols estar sempre mostrant a l'usuari què fer, i que hauria de ser inherent a la pròpia pàgina. 

Quan vostè està pensant en dissenys i burlant-se fins a diferents formes de expressant el seu lloc, vostè realment vol pensar en el que els usuaris van a es fa i com es pot mostrar el que han de fer. Una última cosa és la prova és molt, molt important. És genial tenir algú - demani a un amic, aconseguir a algú que no sap tan sols - que mai ha vist el lloc abans d'utilitzar la pàgina. Com que vostè ha estat treballant en el lloc durant hores, vostè ha estat mirant en això, i vostè sap exactament què fer així que òbviament estarà posant a prova la coses que has estat treballant i que sap treballar. Però si algú ve i utilitza el lloc que mai ha fet servir abans, això és una experiència única, ja tens a algú que no té coneixement previ del lloc d'entrar-hi, de manera que tindrem, de fet ni idea de què fer o quin tipus de casos d'ús estan presents per a ells. Això és genial. Això és únic, ja que són essencialment una persona amb un espai en blanc per a una ment. Ells li poden dir si alguna cosa és confús o poc clar. Ells li poden donar una idea del que precisament l'experiència de l'usuari del seu lloc és. Pot ser molt difícil dir que a tu mateix, de manera que definitivament els animo com vostè està desenvolupant els seus projectes - si estàs fent projectes basats en la web - perquè la gent de fer servir el lloc tan aviat com vostè té algun tipus de demostració funcional. 

Ara vaig a parlar una mica sobre com administrar un projecte de desenvolupament web. Hem revisat com es pot fer la part de fons tècnic, com es pot dissenyar un lloc molt bo, i això és genial si estàs treballant per tu mateix, però - fins i tot si està treballant pel seu compte i especialment si vostè està treballant en un equip, gestió de projectes es converteix en un gran problema. Vostè ha sentit parlar d'una espècie de gestió de projectes en diferents formes des de l'escola primària quan et van dir treball en grup. Vostè ha de cooperar, comunicar, tot això. Tot això encara s'aplica aquí, però hi ha circumstàncies úniques amb ciències de la computació que es vol tenir en compte, i vol assegurar-se que vostè maneja bé. Vaig a parlar primer una mica sobre l'equip que vostè va a estar endins És molt important triar la mida adequat d'un equip que està treballant en, i en el seu projecte final crec que tens l'opció de triar entre 1 i 4 persones, si no m'equivoco. Vostè vol assegurar-se que vostè no està només triant el nombre de persones que vol treballar amb ells perquè són els teus amics. Vostè vol triar un equip que és una bona mida i de fer la feina. Hi ha un descompte comercial a tenir més persones en comparació amb menys gent. Si vostè té més gent, òbviament, més feina es pot fer perquè vostè té un munt de gent, un munt de codi, un munt d'idees, i això és genial. Però també requereix de molta més gestió i molta més comunicació. En altres paraules, si vostè té 4 persones que treballen en el mateix projecte i tots ells estan editant el mateix codi, més o menys que tot tipus de necessitat que ha de saber el que està passant pel que vostè necessita - si s'agrega una funció nova que tipus de ha de dir-li a la gent - estic afegint això, Vaig a canviar això d'aquesta manera - especialment si et fiques en les coses realment profundes igual que els models i els controladors que se'ls influirà en com funciona el lloc. Tot l'equip ha de ser conscient, pel que necessita per assegurar-se que vostè no està triant massa gran un equip que serà difícil per fer que la comunicació. Vostè també no vol triar un petit equip suficient com perquè vostè no va a ser capaç de comunicar perquè és només vostè. 

Una altra cosa a tenir en compte és l'equilibri d'on les habilitats de la gent són. És molt bo si tots vostès són molt bons programadors. Però si vostè és tota la gent de back-end, llavors el seu lloc no va a semblar molt bo perquè vostè té aquesta gran base de dades, i ho fa consultes de cerca súper ràpida - que és gran - però quan vostè va a la mateixa, és com un lloc de 1990 amb vermell i blau a tot arreu, i això no és bo tampoc. Tingueu en compte que Ben i jo treball en equip és molt agradable perquè jo sóc una espècie de més a la part davantera, els dos ens relacionem en la gamma mitjana, i Ben és realment bo amb coses de fons, per la qual cosa funciona molt bé, ja que podem dissenyar qualsevol lloc i, bàsicament, els forats en aquest lloc que necessita ser omplert pot ser omplert per cap dels dos, o possiblement ambdós. Vostè vol assegurar-se que no hi ha forats en el seu equip. Està bé si hi ha una mica de solapament. En altres paraules, si vostè té 2 persones que són bons amb back-end, això pot ser bo també perquè poden ajudar els uns als altres amb problemes que estan tenint. Pot ser un problema si vostè té solament 1 persona que és responsable d'una determinada cosa i es troben amb un problema, de manera que volen tenir una mica de solapament però el més important vol assegurar-se que tots els possibles forats estan plens. 

L'última cosa - i això hauria de ser obvi, però sovint no ho és. De debò vols estar divertint-se. El punt d'aquest projecte final en CS50 i, sovint el punt de desenvolupament web en general, No és simplement fer una feina perquè necessita fer-ho. De debò vols estar divertint, i vol estar fent alguna cosa que motiva a treballar-hi. Si el que estàs fent és un mal per seure i treballar, llavors vostè no està triant el projecte adequat. Vostè voldrà triar una cosa que et sembla interessant, De debò vols veure el resultat, que està emocionat quan arribi una nova idea sobre cosa que podria fer - així que hi ha tot tipus de projectes cal estic segur vostè pot trobar - tothom té alguna cosa que realment intriga ells si estan fent un projecte basat en la web. Ho diré un cop més en aquests moments. Si el projecte sembla com un mal i no vol treballar-hi, triar un altre projecte. Trieu una cosa que realment t'inspira. 

Ben esmenta aquest concepte d'iteració una mica, i jo vull anar una mica. És molt important treballar en ratxes on obté alguna cosa funcional. Pot ser gran si vostè té aquest pla per un lloc web que farà A, B, i C, i amb el temps que arribarà. Però vostè està encallat en aquesta fase en què s'està treballant en ell i treballar-hi, però res és aconseguir que es facin. No té res a veure i una cosa tangible, funcional. El que realment vull fer tot el que sembla una mena de dolor de vegades per treballar en alguna cosa i després una espècie de súmmum pel que és, almenys, en un estable, córrer versió, encara que no té totes les característiques que desitja. I potser hi ha algunes característiques que vostè realment voleu afegir, però que simplement no pot perquè vostè vol aconseguir aquest lloc a un punt de vista funcional. I pel que desitja espècie de tenir a tot el procés de desenvolupament sembla a això. Vols començar en algun lloc funcional - o essencialment començar amb res - però vol arribar a algun lloc molt bàsic i funcional. I, de nou, fer una mena de salt i arribar a algun lloc funcional de nou. Vas a construir lentament, i que podria anar una mica més lent del que seria d'una altra manera, però en el llarg termini si vostè està constantment atrapat en aquesta fase terreny intermedi en què en realitat no té res de treball, pot ser realment una gran frustració per treballar en el seu projecte, perquè sempre estàs tan a prop d'aconseguir que funcioni, i és en realitat mai feina. Vols treballar en aquests dolls funcionals, i vostè també vol fer una reflexió després de cada un. En altres paraules, una vegada que estàs en un punt on el lloc està treballant - que no té tot el que vulgui, però sí algunes coses - que vol pensar, està bé, és aquest lloc el compliment de la meta que em vaig proposar fer? En altres paraules, si el lloc farà X, és el que he treball en la direcció de X? Són totes les funcionalitats que volia allà? I d'altra banda, és que respon a la finalitat general que jo vull? Si vostè està trobant que el seu lloc està començant a virar en una direcció diferent o potser només una mica de les coses no estan funcionant, pot ser el moment de canviar de marxa una mica. En altres paraules, val la pena considerar - val la pena tirar idees si cal i tenint en compte que estic realment treballant cap al que jo vull ser. 

Jo crec que aquest és el meu següent punt. No tingueu por d'abandonar les idees. El fet que vostè va passar un munt d'hores de treball en una funció i, finalment, tinc treball, però en realitat no ho està passant tan bé - com que no és tan útil o els usuaris estan tenint problemes per usar-lo - aquest tipus de coses - no tingui por de llençar a les escombraries. És una merda que vostè ha passat molt temps treballant en això, però en última instància no vols un lloc que és una espècie d'elaborada per aquestes peces que tipus de treball, però no estan tan ben servit. A més, no tingui por d'abraçar noves idees. Si algú ve i diu, hey, aquest lloc es veu molt cool però No seria fantàstic si fins i tot també va fer això? El fet que això és una cosa que no tenia la intenció i és una cosa que no està en el seu especificacions, cosa que vostè no ha proposat fer, no tinguis por de prendre-ho i després treballar-hi. Com que sovint les idees que vostè funciona amb en tot el curs del desenvolupament arribar a ser les característiques interessants de la web. 

Ho he dit abans. Ho diré una altra vegada. Testers són super, super útil. Intenta fer que la gent que mai ha vist el lloc abans d'iniciar la sessió i veure el que està passant ja que no només poden posar a prova la utilitat del lloc i l'experiència de l'usuari, però també poden provar la funcionalitat d'una manera que no es pot. Si feu un tret que fa una cosa certa i vostè sap que va a fer això mateix correctament totes les vegades, això és genial. Però sovint pot ser difícil adonar de casos de cantonada, on ho faria un usuari escriure alguna cosa que no esperaves - precisament perquè ha definit les característiques d'un mateix. Per tant, perquè algú vingués de qui no té idea de com utilitzar el lloc i per simplement trencar de qualsevol manera que poden fer és molt útil, ja que tenir una idea des d'una perspectiva totalment diferent del que al seu lloc web està funcionant i el que necessita ser reparat. 

Finalment, vaig a parlar d'algunes bones pràctiques generals, i que ha vist un munt d'aquests en CS50, però també molt, aplicar realment en una configuració de projecte. Un d'ells és els comentaris. Sempre comentar el seu codi, especialment si vostè està treballant en un equip gran. Pot ser molt molest tenir només un gegantí bloc de codi que algú ha escrit i potser funciona, potser no ho fa, però no tens ni idea del que fa, el que no tenen idea de si és útil o no, o si hauria d'estar allà o no, i si vostè està treballant en una altra cosa que és fins i tot possible que vostè està treballant en el mateix, així que tingues molta, molta cura per ser considerat amb els seus companys i el codi d'escriptura que està ben documentat. Vostè no ha d'anar tan lluny com per fer tot l'assumpte en què li agrada si incrementes un comptador té un comentari que diu que estic afegint 1 a aquest comptador. No ha de ser detallat, però per a qualsevol funció que vostè està sempre escrivint vostè ha de tenir algun tipus de documentació del que la funció fa exactament, el que els seus entrades són, i el que han de tornar. D'aquesta manera vostè pot utilitzar altres components de la gent del lloc i vostè pot treballar en la construcció d'alguna cosa gran. 

Una altra cosa important és que vostè vol fer neteges regulars. Codi es complica. No es senti malament si el seu codi és totalment il · legible i un embolic gegant. Això succeeix en el desenvolupament web sempre. Heu afegit noves característiques, l'eliminació dels antics. Les coses estarà allà que no hauria d'estar. Això està bé, però vull assegurar-me fer front a aquesta regularitat. No vol deixar que s'acumuli fins al punt en que no es pot trobar res en el codi, i no tens idea del que fa qualsevol cosa. Aquest és el cas d'HTML. De vegades vostè va a acabar amb els objectes que no contenen res, i vostè vol desfer-se'n. En CSS, pot estar referint-se als elements que no estan més allà, pel que desitja desfer-se d'aquest codi. En JavaScript, potser hi ha eliminat alguna cosa de l'HTML. Així doncs, vostè vol assegurar-se que vostè està sempre netejant, fent les coses bastant com tot el que pugui sobre una base regular. 

Una altra cosa molt útil que no crec que es perfila molt a CS50 però val la pena entrar és el control de versions. La idea de control de versions és quan estàs bàsicament fer el seguiment de tots els avenços vostè ha fet cap al seu lloc i si en algun moment t'adones, oh, això també estava treballant Fa un temps, però que no funciona més, pot tornar a les versions anteriors i veure el que ha canviat des de llavors, i aquest tipus de coses. La principal manera de fer-ho és amb Git, i Git és tot aquest tipus de sistema que Crec que Tommy MacWilliam impartir un seminari sobre l'any passat. Si vostè entra en els seminaris CS50 per a l'any 2011, es pot veure el seu seminari sobre això. La idea d'Git és bàsicament que a intervals regulars que vostè està fent aquests compromisos que són formes de dir el lloc està en una versió bastant estable en aquest moment per Estic empaquetar i enviar lluny a un servidor, i llavors vostè pot anar a aquest servidor i miri totes les versions anteriors del seu codi i veure com ha progressat i tot aquest tipus de coses bones. Llavors, això és bàsicament tot. Pel que fa a desenvolupament web, estarem encantats de quedar-se i respondre a qualsevol preguntes pel que fa a la nostra presentació. Això és tot. Gràcies. >> [Ben] Gràcies. [Aplaudiments] 

[Billy] Personal, algú té alguna pregunta sobre les coses que hem cobert o coses que no hem cobert que esperaven que havien cobreixen? Estaríem encantats de respondre-hi. Algú? [Membre de l'audiència] Quins són els pros i els contres de l'ús de Ruby o usant Python? [Ben] La pregunta era, quins són els pros i els contres de l'ús de Ruby o Python en comptes de com PHP. Els pros són que Ruby i Python són molt millors que les llengües PHP. Almenys al meu entendre, i crec que en un munt d'opinions d'altres persones també. Van ser dissenyats per fer coses més complexes, i menys per colpejar junts pàgines web molt ràpid amb una mica de contingut dinàmic. Els desavantatges són que hi ha una mica de - hi ha més d'una corba d'aprenentatge Per arribar a establir. És a dir, igual que en PHP, només pot tenir un arxiu HTML i escriure-menys, signe d'interrogació, i després a escriure una mica de codi, i després s'escriu un signe d'interrogació més gran que, i després ja està. En altres idiomes com Ruby o Python, vostè ha de passar per una mica més de treball per aconseguir el lloc en funcionament inicial. També hi ha - almenys el que solia ser el cas - que hi ha més documentació disponible per PHP simplement perquè hi ha més persones que l'utilitzen. Crec que això no és tant d'un problema més. Certament hi ha una documentació molt bona per a coses com Ruby on Rails o Django per Python és l'equivalent. PHP és el que tothom ha estat utilitzant durant anys, i ja saps com funciona. Ruby, Python són una mica menys madurs. 

[Membre del públic] Si hagués de triar entre un d'ells per aprendre o recollir, que prefereix? Honestament, crec que això depèn de la persona. Ho sento. La pregunta era quin triaries perquè algú aprengui? Em sembla Python el millor personal. Hi ha un munt de persones que - vaig fer el meu primer projecte dev web en Python i Django. Hi ha un munt de gent que li agrada Ruby on Rails també. Probablement més gent sàpiga de Ruby on Rails. Honestament, m'acaba d'anar amb el que les persones que t'envolten saben quedant amb la gent a fer preguntes. 

La pregunta era - en servidors compartits és una mica difícil de treballar en Python? Això depèn del teu hosting. Hi ha un nombre de servidors web de publicar coses Python. WebFaction fa això, oi? WebFaction és un que Billy i jo hem utilitzat per a alguns projectes. Són realment genials. Ells donen suport a la majoria dels idiomes. Però és cert que PHP és recolzat molt més àmpliament. Així doncs, si vostè està encallat en un proveïdor d'allotjament web que només fa PHP, que és una bona raó per utilitzar PHP. 

[Membre de l'audiència] Acabo d'arribar a aprendre com consultar algunes bases de dades, i sé que el meu SQL és per tot el lloc, però Recentment m'exposo a - i vostè s'ho va assenyalar. Vostè veu JSON i bases de dades extensibles. My SQL encara és per tot el lloc. Com veu vostè que això passi? Hi haurà una tendència creixent per a més expandible (inaudible)? La pregunta era: - No crec que hi haurà una tendència cap a les bases de dades no SQL. Per exemple, com MongoDB. Crec que això és definitivament cert. El meu consell va ser majoritàriament relacionades amb mySQL mySQL aquí només perquè és estàndard de la indústria. Personalment, m'agrada molt més les bases de dades que no tenen schemos com MongoDB on vostè no té el problema de, oh, he de afegir una altra columna. Ai de mi, com ho faig? És molt difícil fer això en MySQL, però quan vostè té una mena Mongo és molt més agradable. L'altra cosa bona sobre Mongo és que els seus registres són en realitat objectes JavaScript. No hi ha cap mena d'etapa de conversió en el qual ha de prendre aquestes files de base de dades i convertir-les en un objecte de JavaScript i després enviar-los a través del cable. Crec que aquest tipus de coses serà molt, molt útil per al desenvolupament web ràpid en el futur. 

[Billy] Una cosa que m'agradaria afegir que és només un punt general és que no se sent com que hauria d'haver après tots els idiomes que hem discutit del nostre seminari. Òbviament, el punt és que et facis una idea del que hi ha per aquí, i si vostè està intrigat per cap de les coses que hem esmentat que vostè pot buscar en Google els i llegir sobre ells. I com ja he dit, hi ha alguns seminaris que tracten precisament aquestes coses. Hi ha encara més seminaris que no he esmentat que probablement entrar a aquestes coses també. La idea és que si vols treballar en alguna cosa, aquí estan les eines a la seva disposició. No se senti aclaparat si no està realment segur del que aquestes eines fan exactament, però saben que hi són fora i que vostè pot fer un ampli ús d'ells per Google. 

[Membre de l'audiència] Quin tipus de coses que cal fer per assegurar-se que el seu lloc web es veu bé en els dispositius mòbils? [Billy] Els dispositius mòbils són una mica dures. Hi ha 2 maneres d'abordar-. La primera forma és que vostè realment té un lloc web per a mòbils. En altres paraules, ha de realitzar algun tipus de detecció en l'inici quan el navegador està fent la sol · licitud al seu lloc web que, o bé diu tornar aquest punt de vista - que serà el punt de vista dels navegadors d'escriptori o portàtil - i aquest altre punt de vista per a dispositius mòbils. Aquest és un lloc on les vistes són realment agradable que vostè pot força molt l'intercanvi 2 fora i tenen una interfície que funciona molt bé en els dispositius mòbils i tenen una completament diferent, que funciona molt bé en els dispositius del navegador. El problema amb això és que es necessita molt de temps, ja que significa la codificació una interfície totalment diferent. L'altra forma en què vostè pot fer és - una gran quantitat de telèfons moderns mostrarà llocs web i tractar de fer-com un navegador faria, i fan tot el possible. Pot espècie de tractar de mantenir la llum de la quantitat de jQuery JavaScript està utilitzant que tendeix a ser on les coses poden anar malament una mica. Aquesta és una espècie de la forma en què s'ha d'utilitzar si no té aquesta quantitat de temps. Si vostè té el temps per treballar en una interfície mòbil, això és, òbviament, el millor. 

Crec que en general, per als projectes de CS50, vostè va a voler triar un o altre. En altres paraules, vostè vol fer una aplicació mòbil o desitja fer un lloc web d'escriptori. I aquest tipus de determina on vas amb això. Però si vols expandir més tard, probablement la seva millor aposta és per fer una altra interfície per a l'altre. Tinc una mica d'experiència en el desenvolupament de llocs basats en WordPress. Em vaig organitzar un web en WordPress per una estona. Aquest tipus de marcs poden ser bones coses molt bàsiques. Moltes vegades vostè només es troba amb un munt de qüestions de personalització però. Vostè voldrà tenir una mica mirar de certa manera o sigui de certa manera i vostè simplement no pot perquè està connectat rígida al sistema que així és com cal fer les coses que poden ser una mica d'un problema. Des de llavors he mena d'estat més disposats a treballar amb els llocs de la terra cap amunt. Per coses com les bases de dades del bloc i aquest tipus de coses no és realment tan difícil de construir un marc. Si vostè està realment estirat pel temps, es pot utilitzar, per descomptat, una mena de WordPress o aquest tipus de coses per a un bloc. El tipus de coses que els blocs botiga i fer no són realment prou dur que si s'està executant en cap d'aquestes coses, vostè és probablement el millor penes fer una versió de la casa. 

Crec que això és tot, així que gràcies de nou per venir. Realment gaudim de parlar amb vostès i espero que hagis après algunes coses. [Ben] Estem encantats de parlar - hem d'anar, però estem disposats a parlar més a l'exterior si vostè té una altra pregunta. Gràcies de nou. [Aplaudiments] [CS50.TV]