[Powered by Google Translate] [Seminario] [Desenvolvemento web: Da idea á implementación]
[Ben Kuhn] [Billy Janitsch] [Universidade de Harvard]
[Isto é CS50] [CS50.TV]
[Billy] Ola, eu son Billy e este é Ben. >> [Ben] Hi
Nós imos estar fala de desenvolvemento web hoxe.
[Webdev] [Billy Janitsch e Ben Kuhn]
Un pouco sobre nós en primeiro lugar.
Ben é o tipo de cara back-end. El fai as cousas funcionan.
E entón eu entrar e facelos fermosos.
Estou en gran parte implicada con máis front-end tipo de proxecto de deseño de cousas,
e Ben, por outra banda, sabe o que está facendo para que funciona en cousas back-end.
Xuntos fixemos algunhas cousas.
Por exemplo, o ano pasado traballamos en Gimblium que é un estudo de desenvolvemento de xogos online.
Ese era o noso proxecto final para a clase,
e desde entón fixemos Harvard Clase
que é unha estrutura en liña para navegación e cursos de compras en Harvard.
>> Imos comezar con esa idea para o noso sitio.
Nós imos facer o Facebook, pero para gatos.
Antes de que realmente facer esta web,
non fan esta web porque non é bo, pero imos usalo como un cadro
e pasar polo proceso de como podemos levar esta idea
e transformalo en un sitio real que podemos utilizar.
Imos comezar por romper o sitio para abaixo.
Como ten feito o CS50,
quere pensar sobre cales son os compoñentes reais que van para o web.
Basicamente transformando-o de unha idea que non é máis que unha especie de un concepto abstracto
nunha cousa real e tanxible que podería facer.
Comezamos a facer algunhas preguntas.
¿Que é este sitio? Por que estamos a facer iso?
Que é o que vai ser usado? Ese tipo de cousas.
No caso de Facebook Gato,
que basicamente quere un sitio web que permite que gatos rede social co outro.
A idea é que poden publicar en cerramento de cada un,
poden facer comentarios, este tipo de cousas.
E é aí onde entramos en compoñentes funcionais.
Temos, agora, este tipo de estrutura de - temos perfís de usuario,
temos comentarios, e podemos publicar.
Quizais un día imos afluente gustos e ese tipo de cousas.
E nós medio que quero priorizar estes recursos que van dentro
Queremos dicir como, ok, é moi importante que todos teñan un perfil
e que todos poidan publicar no paredes de cada un.
Secundario para que, os comentarios sería bo.
Quizais máis tarde imos afluente gustos.
Entón, quere ter unha idea do que é fundamental para o seu proxecto
eo que é unha especie de característica máis xeral que podería ser aplicado máis tarde.
Quere que a sorte de ter unha lista específica en mente,
mais o proxecto que comece con non será o proxecto que rematar con.
Noutras palabras, as cousas van cambiar mentres está a desenvolver o sitio web,
e quere deixar espazo para iso.
Vou entrega-lo para Ben, que vai falar un pouco sobre a estrutura.
>> [Ben] eu vou estar falando sobre o lado máis técnico de desenvolvemento web.
Imos pasar por riba de algúns principios básicos en primeiro lugar.
Cando está facendo unha aplicación web,
a división principal que vai ter que ter é
vai ter algo suceder no lado do cliente -
ou sexa, o código que che navegador leva dende o sitio web
eo JavaScript, HTML, CSS cousas.
Isto é todo no lado do cliente.
Terá outro código que se executa no lado do servidor
que mantén o control de todos os datos que a xente envían para ti,
decide quen dar o que, cousas así.
Este é só un pouco de terminoloxía, de xeito que vostedes están familiarizados co que estamos a falar.
Alén desa división, é bo pensar na súa aplicación web en termos de
un par de compoñentes distintos.
Cando está facendo desenvolvemento web
unha das cousas que ten que estar sempre intentando facer é reducir a complexidade.
Canto máis complexo o seu código é o máis posibilidades hai de facer erros,
o que é máis difícil cambiar máis tarde.
Entón, se pode romper a súa aplicación nalgunhas áreas funcionais distintas
que vai - e pode reducir o tipo de cantidade de comunicación da zona de cross -
que pode axudar moito no longo prazo en termos de redución de erros.
>> Para ser concreto, xeralmente a xente divídense en unha aplicación web -
estes son o tipo de palabras de moda agora, pero eles aínda son útiles.
Pode ter oído a xente falaren sobre modelos, visualizacións e controladores.
Os modelos son os datos reais que a súa aplicación vai a tratar con eles.
Por exemplo, no seu gato Facebook, os seus modelos sería -
que tería un modelo para as mensaxes como, e un modelo para perfís de usuarios, cousas así.
As súas opinións son como presentar estes datos para os seus usuarios.
Pode ter unha vista para mirar a un único post e todos os comentarios
e unha visión diferente para a súa fábrica que ten unha lista de todas as mensaxes
que son dirixidos a vostede, e unha visión diferente para o teu feed de noticias - cousas así.
Por último, ten os controladores que son basicamente cando a xente enviar mensaxes
e fai actualizacións para o sistema de back-end,
vostede incrementa unha morea de contadores, e calquera que sexa.
Estes son os seus controladores.
>> Vou estar falando principalmente sobre os modelos.
Visto que non son tecnicamente difíciles e a cuestión é máis co proxecto-los
Controladores van ser específico para o que está designado.
Pero hai algunhas técnicas moi xerais que pode usar
para facer os seus modelos máis agradable e máis fácil de traballar que eu creo que son moi útiles.
Isto é principalmente será sobre como xestionar os seus datos aplicacións web de forma agradable.
Os principais problemas cos modelos
son eles os que viven no cliente e do servidor e ten que descubrir
a) como obtelos - todo relevantes - dende o servidor ao cliente,
eb) como mantelos en sincronía.
Os usuarios van querer facer algunhas actualizacións.
Eles van querer facer novos artigos.
Eles van querer gusta de cousas e cousas, se ten gustos.
Estes son os principais retos técnicos de manexar modelos.
O primeiro que vai querer preguntar a si mesmo é
que tipo de datos vai neste modelo e que tipo de procuras que imos querer facer -
é dicir, como é que imos ollar os modelos?
Para o gato exemplo Facebook,
seu post vai ter un autor asociado a el,
texto pos parede, e un receptor da mensaxe no mural.
E entón podes querer consultar que en unha morea de xeitos diferentes.
Desexa miralo por que escribiu que post,
por que recibiu o que publicar, quizais pola data en que foron publicados.
Pero se está indo facelo por data, así que ten que engadir outro campo para o seu post
de cando foi realmente lanzado.
Estes dous factores - o que os datos que quere usar e como quere velo -
ten que pensar sobre eles, en primeiro lugar porque dependen uns dos outros,
e iso vai ser máis difícil para engadila los máis tarde.
>> Existen algunhas outras consideracións.
Cando está a pensar sobre como trata con modelos no servidor
o que quere é mirar para -
basicamente quere facer o servidor o máis sinxelo posible.
Facer cousas no lado do cliente é xeralmente moito máis rápido se pode facelo só no cliente
sen facer calquera tipo de solicitude de rede.
A idea é facer o maior número de consultas que poida sobre o cliente.
O único problema con que
é que se pedir todos os seus datos no inicio
logo que vai levar moito tempo para cargar.
Entón, a idea é atopar un medio termo entre ter datos suficientes sobre o cliente
que se pode facer a maioría do seu traballo alí, pero non só buscar todo dunha vez
para que obteña os tempos de carga moi lento no inicio.
Por exemplo, para o gato de datos
probablemente quere buscar unha morea de mensaxes de parede recentes.
Non quere incorporarse todos eles, xa que o que podería dar cara atrás un par de anos.
Pero non quere busca-los un de cada vez
porque iso ía introducir unha gran cantidade de sobrecarga da rede.
>> Moitas veces é moi difícil - xa que ten unha base de datos en execución -
moitas veces é moi difícil cambiar os datos que ten nel -
ou sexa, engadir unha nova columna de base de datos ou algo así -
así unha boa estratexia é, en realidade, só para manter unha morea de seus datos nun blob de texto -
unha burbulla JSON - JSON sendo JavaScript Object Notation -
A razón pola que isto é útil é porque entón podes engadir novas propiedades
a todas estas burbullas JSON sen alterar o seu banco de datos.
A única desvantaxe para iso é que se ten unha morea de campos
que engadiu máis tarde - como oculto no que blob JSON -
entón é máis difícil de consultalo-los dentro da base de datos.
Por exemplo, se máis tarde - se tivo o seu modelo de post que discutir anteriormente
só co autor, o destinatario eo texto -
Tamén pode ter unha burbulla JSON e, a continuación, máis tarde quere engadir un campo de data
non ten que cambiar o seu banco de datos.
Podería só engadir as datas para todos os campos de texto.
E entón sería capaz de ollar para aqueles no lado do cliente,
pero non sería capaz de consultalo-los no lado do servidor
porque está oculto dentro deste texto.
>> A outra cuestión que quere pensar sobre
É así que o seu cliente e servidor vai comunicarse.
Vostede xeralmente queren manter este tan sinxelo que pode.
Pode só ter como un me-get esta solicitude de datos,
a crear a new-object cousa, e unha solicitude de actualización, un vello-obxecto-.
E estes serían todos diferentes URLs nun servidor que -
que o navegador - podes usar solicitudes de AJAX para todos estes
e recibir ou datos de mensaxe.
Unha vez máis, ao noso gato exemplo Facebook,
podería ter a URL para obter unha mensaxe individual,
e que tería unha URL para crear unha nova mensaxe no mural
e quizais un URL para subir a súa foto do perfil, cousas así.
Pero, de novo, iso é a pre-busca a maioría dos seus datos para que non ten que manter
facer solicitudes de rede.
Por esa razón, non pode querer ter esta solicitude get individual para un único post,
e no seu lugar só quere unha solicitude get para a parede enteira.
E entón, se está tentando atopar un equilibrio, pois -
iso tamén dependerá da súa aplicación.
Porque se está esperando que as persoas teñen só 10 ou 20 mensaxes de parede
que se ve ben.
Pero se está esperando que teñen miles entón esta proposta vai levar moito,
e así que pode querer engadir un get-all-mensaxes-desde parámetro.
>> Por todo iso probablemente vai querer sincronizar os datos en JSON -
JavaScript Object Notation.
Practicamente todas as linguas manexa JSON moi ben.
JQuery ten esa función getJSON agradable que vai facer todo o traballo duro para ti.
E no PHP hai tamén moi agradables funcións de comunicación JSON.
Entón, iso é probablemente o mellor formato para o envío dos seus modelos e cara atrás.
>> Como un exemplo do que falamos ata agora,
aquí está un exemplo de fluxo para o gato aplicación de Facebook.
Ela comeza co seu navegador solicitando a URL do sitio base.
O servidor probablemente ía enviar máis de HTML estático e un pouco de JavaScript e CSS.
Xeralmente é mellor non facer calquera procesamento do servidor.
Probablemente non quere -
que o servidor non está facendo alí vai para abaixo a lista de postos de parede
e xerar algún código HTML para cada un e de envío que rematou.
Xeralmente é mellor para facelo do lado do cliente, xa que en caso contrario
cada vez que quere re-deseñar algo, ten que facer unha solicitude do servidor.
E iso moi rapidamente dálle unha morea de arriba.
Xeralmente é mellor só para navío envía HTML estático
e logo, JavaScript e CSS que vai facer a renderización do lado do cliente.
Así que o material chega,
entón vostede pode ter - en JavaScript - podes facer pedidos para os datos de parede
e cousas así, e despois de que o servidor está basicamente facendo consultas de bases de datos
e comprobar os permisos.
O único importante é que el non pode enviar máis algúns outros usuarios mensaxes de parede
que non ten permiso para ver.
Basicamente, pode ser unha capa de acceso a moi fina para a súa base de datos,
e, a continuación, toda a mostrar os datos - todos os puntos de vista e outras cousas -
quen poden ocorrer no seu navegador, e entón cando quere facer un post ou algo
acaba de enviar outro pedido.
>> Tamén hai algunhas cousas extravagantes que podes facer enriba diso.
En termos de información técnica máis específicas,
desenvolvemento en JavaScript simple pode ser un pouco doloroso,
por iso hai algunhas bibliotecas e ferramentas que han axudar moito con iso.
Eu creo que todos vostedes xa debe ter oído falar sobre jQuery que fai facer renderización HTML
e manipulación moito máis doado - ten unha morea de funcións de fantasía para entrando e saíndo,
e facer animacións zippy.
Tamén esta biblioteca chamado Underscore.js.
Ten unha morea de funcións de utilidade útil, cousas que esperar JavaScript ter
que realmente doesnt - cousas como embaralhar un array,
eliminación de duplicados de unha lista, ou achatamento unha lista de listas.
Esta é só unha pequena mostra de código.
Subliñado ten unha toneladas desas funcións interesantes que quere que tería todo o tempo.
>> E despois hai unha biblioteca que me gustaría pasar un pouco de tempo en
chamado Backbone.js por Backbone realmente axuda a xestionar modelos no lado do cliente
e unha morea de confusión que isto pode causar.
Backbone dálle ese concepto de modelos e coleccións
en JavaScript que son basicamente exactamente como obxectos JavaScript
en matrices de JavaScript, pero eles teñen eventos cando cambia as súas propiedades.
Así como no Javascript, pode ter un evento cando un botón é premendo ou algo
estes modelos Backbone e coleccións Backbone ha transmitir cousas como
que cando cambian.
Isto significa que pode simplemente escribir algo como este fragmento de código aquí -
este di que, sempre que engadir calquera cousa para a matriz mensaxes que redeseñar toda a parede.
E isto dicir sempre que o número de un posto de gusta de cambios,
vostede notificar o usuario de que alguén gusta do seu post.
Ou sempre que calquera propiedade dun posto de cambios que redeseñar o post.
Cousas así vai aforrar toneladas de complexidade, porque se non
se non ten un cadro coma este, a continuación, cada vez no seu código que cambie
nada sobre un post, ten que lembrar-se de chamar todas as funcións fan
e cousas así, e se quere engadir algo novo que pasou
cada vez que modificou un post que ten que pasar por todas as partes na súa
código que modificou un post e engadir que cousa nova.
Unha estrutura como esta vai eliminar unha morea de que a comunicación entre capas
que fai que o seu código complexo e difícil de manter.
>> Hai algo sobre puntos de vista tamén.
Vou deixar a maior parte deste para Billy, porque eles non son tecnicamente moi difícil.
Use jQuery para os seus puntos de vista. É practicamente como unha necesidade neste momento.
El só fai todo moito máis fácil.
Hai unha gran cantidade de bibliotecas.
Se ten complicado elementos de interface de usuario,
se quere unha cousa auto-completa ou como unha desas varias selectores de fantasía -
se quere algo así, probablemente debe só buscar por aí
e pode atopar unha boa biblioteca que vai facer o que quere.
Billy vai explicar máis sobre as partes realmente difíciles de puntos de vista.
Ademais, como unha nota lateral, Backbone ten algunhas características para facer visualizacións comunicar
moi ben con modelos - ollar a documentación para todas estas bibliotecas, en realidade.
Basta ollar os docs. Son moi ben escrito e doado de seguir.
En xeral, pode moi ben só Google se ten problemas.
Hai unha gran cantidade de persoas que os utilizan.
Eu creo que iso é como unha nota final.
>> Tamén hai algunhas cousas máis avanzadas que podes facer
se está a buscar para facer a súa aplicación web extra incrible.
Podes facer - a nova especificación HTML5 ten unha morea de cousas extravagantes que podes facer.
O almacenamento local - o que é que pode almacenar datos no navegador -
en vez de ter que volver e ler o servidor para todo,
pode manter un pouco a el no cliente e que permite incluso persoas -
nalgúns casos, pode incluso deixar usar a páxina fóra de liña.
Non hai esa cousa chamada websockets que son un tipo de comunicación de rede
onde no canto de só lle facer unha petición, que obtén a resposta e está feito,
manteña abrir unha conexión co servidor e para que poida facer cousas como
actualizacións en tempo real.
Entón, se estaba tentando facer unha aplicación de chat, pode utilizar websockets
para comunicarse e para atrás de xeito que non ten que manter o solicitante,
"Oh, servidor, alguén me enviar unha conversa?" cada 10 segundos ou algo así.
Hai tamén un recurso de HTML5 interesante, onde podes facer parecer que
a URL da páxina está cambiando, sen nunca ter que recargar-lo.
Podes usar botóns Voltar e avanzar sen facer unha chea de peticións de rede.
Cousas como esta é realmente útil en termos de facelo rápido, pero tamén funciona como unha aplicación web debería.
>> Hai tamén unha cousa chamada CoffeeScript.
CoffeeScript é unha linguaxe diferente, en realidade, que compila abaixo para JavaScript.
Podería escribir todo o seu código en CoffeeScript, a continuación, executar este compilador,
e el Cospe un arquivo JavaScript que pode incluír na súa páxina web.
A razón que CoffeeScript é bo é porque se librar de unha chea de
casos estraños que Javascript ten que equivale iguais,
e iguais iguais facer cousas distintas, ou gusta -
el ten unha sintaxe máis agradable para xestionar matrices e funcións.
Este é un pequeno fragmento de CoffeeScript que produce unha lista de todas as prazas
a partir de 10 ^ 2 a 1 ^ 2 en orde inversa.
Como verás, CoffeeScript frecuentemente permítelle expresar nunha liña
o que levaría 5 liñas de JavaScript.
Pode facer cousas moito máis fáciles.
É un pouco de nova sintaxe para aprender en primeiro lugar,
pero definitivamente vai facer máis produtivo no longo prazo.
>> Tamén pode usar outros idiomas no servidor de PHP -
linguaxes como Ruby, Python, ou hai aínda un proxecto chamado node.js
que permitirá que use JavaScript no servidor.
Persoalmente, realmente, realmente odeio PHP.
Eu só non me gusta de traballar con el.
Se tamén cre que é unha cluge terrible dunha lingua,
entón podes usar un destes no seu lugar.
En xeral, se quere facer algo e realmente non sei como podería facelo,
pode buscar en Internet.
Hai toneladas e toneladas de recursos, sobre todo en -
StackOverflow é un gran home.
É o sitio onde os desenvolvedores preguntas uns a outros.
Pode que executar para el, se estaba a ter problemas en conxuntos de problemas CS50.
E hai toneladas de bibliotecas para facer practicamente calquera cousa que quere.
Se queres facer algo e non sabe como facelo,
non pense que é imposible.
Basta ollar arredor e podes atopar uns bos recursos.
>> Como un xeneral finalizar,
os principais delivery son manter as cousas simples.
Canto máis complexo o seu código está no inicio
e canto máis lle tentar e facer cousas extravagantes,
o que levará máis tempo para conseguir algo realmente funcional
eo máis difícil será para cambiar máis tarde.
Entón, fai as cousas da maneira burra, fácil primeiro.
Para ir xunto con iso,
non teña medo de xogar fora código antigo ou limpa-lo moito.
En xeral, xa que o que realmente ten algo de traballo,
é moito máis doado para pensar que cando aínda está en etapas iniciais
de como fago para poñer todo iso xunto.
É mellor facer o proxecto máis idiota posible que traballa
e entón mellora-lo de forma iterativa do que tentar facer todo certo na primeira vez.
En termos de división de cliente-servidor, e intentar manter o seu servidor moi simple -
só unha base de datos e algúns de autenticación e non fago calquera traballo duro alí.
Efectúe todas as súas cousas complicadas no lado do cliente no seu navegador
en JavaScript, tanto como poida.
Olhe arredor de bibliotecas que fan a súa vida mellor.
Sempre é mellor usar o código que alguén escribiu
se - e non para gravala-lo ti mesmo.
Hai unha morea de cousas en Internet. Google é o seu mellor amigo.
Google é o mellor amigo do programador.
Si, definitivamente non teña medo de ollar ao redor para outras cousas.
Todo ben. E ao longo de Billy.
>> [Billy] De feito, antes de comezar con algunhas cousas deseño,
Alguén ten algunha pregunta para Ben sobre calquera cousa que el falou?
Correcto, bo.
Unha vez máis, deixe-nos saber se algo non está claro
ou se desexa nos pasar por riba de algo un pouco máis.
Eu vou volver un pouco e falar sobre as partes máis fundamentais de deseño.
Ben mencionar o modelo chamado - Sentímolo, o modelo de sistema de visión controlador
que é unha especie de aspecto técnico, entón eu vou mirar a vista, en concreto,
e eu vou comezar coa forma como proxectar unha visión que parece bo.
Aquí é unha especie de modelo moi básico para o noso gato Facebook.
Eu creo que hai algúns fundamentos en deseño de interface de usuario moderna
que pagan a pena ir.
Pode notar que hai unha morea de espazo en branco por toda a páxina,
moito espazo para as cousas.
Non sinto que ten para esmagar as cousas nunha páxina.
Quere deixar moito espazo aberto, e se é en calquera sitio moderno
vai ver que non hai branco en todas as partes.
Hai branco en lugares que non esperaría.
Ten esa paleta de cores, e é sabio ao comezo
para escoller unha paleta de cores que vai traballar e desenvolverse.
Tamén - el axuda a escoller un tipo de letra, e de que xeito está tipo de traballo con
estes fundamentos concretos do proxecto.
Ten o seu tipo, ten as súas cores, e entón pode tipo de
caber todo na tan necesaria.
Entón, como eu dixen, co seu esquema de cores que desexa utilizar as cores máis ousadas do seu esquema de cores
con moderación. Cabeceiras son agradables. Botóns son agradables para ter realmente grandes, cores chamativas.
Pero, en xeral, se tes un sitio web que ten as cores en todas as partes,
todos mirando na cara, el só parece confuso, e iso non é bo.
Quere usar xeralmente cores claras.
Probe, unha vez máis, escoller un esquema de cores moi coherente.
Pode que estes pequenos salpicaduras de moita memoria -
que pode parecer moi bo, pero quere usalos moi moderación.
>> Como dixen, quere ser mínima. Menos é sempre máis.
Se pode amosar algo ou non presentar algo,
e vostede é do tipo sen saber se el debe estar alí por defecto -
probablemente é o mellor deixala fóra. Sempre pode engadir lo máis tarde.
Si, manter as cousas simples.
Pero o máis importante, quere considerar varios proxectos.
Non pense que cando fai un sitio web, telo na súa cabeza que vai
facer o sitio web dunha determinada maneira, e só pode ser exactamente así.
Terá a cabeceira azul na parte superior ea barra lateral azul
e entón a cousa sub-cabeçalho amarelo.
Quere facer varios modelos.
Pode - se é bo con Photo Shop, pode abrirse e que tipo de
crear un sitio web como lle gusta de ollar.
Se non, pode só usar papel e pluma,
pero rabuñar a varios proxectos.
Quere ter basicamente un set-up, onde ten lotes de proxectos diferentes,
e se alguén acaba de traballo, entón iso é gran.
Se alguén acaba fallando, entón sempre ten outro a quen recorrer.
En xeral, non se senten como ten que ser limitado
para calquera proxecto que inicialmente decidir.
O deseño é moi variable, e de parte da importancia do modelo
sistema de visión controlador é que pode cambiar dentro e fóra puntos de vista diferentes que quere.
Pode influír os datos dun xeito, e entón decidir, oh, en realidade, iso non funciona moi ben.
Eu creo que é tipo de demasiado complicado ou hai unha parte aquí que non está realmente traballando,
entón eu só vou abandonar totalmente este punto de vista e de intercambio de forma totalmente nova.
Aínda os podemos empregar os modelos antigos e os antigos controladores.
Podemos facer todo no servidor e cliente como sería antes.
Pero a onda real dos datos como presentado será lixeiramente diferente.
>> Canto realmente aplicar o proxecto que quere,
xa que ten algúns proxectos esbozados en papel ou Photo Shop ou calquera outra cousa,
hai unha serie de ferramentas que están dispoñibles para ti.
O primeiro que está moi familiarizado co que é o seu HTML, PHP, ou calquera outra cousa
linguaxe que está a usar só para codificar as páxinas estáticas na súa páxina web.
Vostede traballou moito con HTML, que tipo de dálle estas etiquetas
que pode poñer as cousas en, e, basicamente, é unha forma de organizar o seu contido.
Por exemplo, ten a cabeceira alí enriba, entón vai ter unha etiqueta de cabeceira,
e só pode ter un texto dentro del o que probablemente vai ser noutra etiqueta.
Así que ten unha barra lateral, quizais con algúns enlaces diferentes,
e os que van ser todos en separar as etiquetas.
Entón, basicamente HTML no seu corazón é unha forma de dividir a páxina como
vostede eventualmente quere formato-lo.
Entón, de novo, xa viu iso antes.
Vostede é moi cómodo co traballo con el agora
unha vez que fixo a última pset esperamos,
de xeito que non debe ser problema.
>> Entón tes CSS que basicamente se encarga de todos os aspectos de deseño estáticos.
Sería xestionar todas as cores, todos do posicionamento de diferentes elementos,
onde se atopan con respecto un ao outro,
como son grandes, os distintos tipos de posicionamentos que tería -
noutras palabras, pode que as cousas fixas de xeito que cando rolar para abaixo eles quedan,
ou pode que as cousas con respecto a outros elementos.
Todos este tipo de cousas é en CSS.
Ademais, pode facer diferentes decoracións, pode ter as cores do texto,
efectos de texto, todo este tipo de cousas.
Ben deu un bo seminario sobre este último fin de semana,
e entón eu sempre comprobar iso, se pretende estar facendo algunhas cousas extravagantes con CSS.
CSS3 é realmente a máis nova versión do CSS, e pode facer todo tipo de cousas realmente agradables.
Pode facer degradados, pode que agradables, cantos redondeados, pode facer todo tipo de cousas
para facer o seu sitio web ollar máis moderno e chique.
>> A seguinte ferramenta é Javascript e jQuery que Ben falou un pouco sobre,
pero eu vou estar un pouco máis cara a dentro.
JavaScript, como traballou con el un pouco, ou polo menos visto en clase,
é unha especie de modo de facer cousas de forma dinámica en HTML.
HTML, como vostede sabe, é estático, entón cando ten HTML non pode modificalo.
Pero JavaScript, de certa forma, é un xeito de poder modificar HTML.
Así, pode facelo, e iso é gran, pero JavaScript é realmente unha dor de traballar.
É tan longo e obtuso e facer incluso as cousas máis simples
require lotes de liñas de JavaScript.
Entón, jQuery é basicamente unha biblioteca para JavaScript que simplifica todo isto.
Ela di, todo ben, se quere ter unha caixa cadrada veñen de esquerda
e desaparecer na páxina para que está no medio, en JavaScript que levaría -
Eu non sei, cen liñas que facer, e que sería unha dor,
e saír dela odiando todo sobre programación web.
JQuery ten basicamente o elemento-dot-fade-in, ou algo así.
Funcións Así, moi, moi simple que permiten que fai todo tipo de animacións divertidas
e ese tipo de cousas.
A outra cousa que estes dous son realmente bos para só está facendo cousas dinámicas
co sitio.
Entón, en vez de só ter a súa páxina HTML - que amosa algúns datos, pero en realidade non
facer nada - Javascript e jQuery vai deixar que ten botóns que pode facer clic en,
e pode arrastrar elementos e re-forma-los e clasificalos los, e ter novos elementos
engadido ou eliminado. Podes engadir-delete, este tipo de cousas.
Entón, jQuery fai toneladas de cousas legais.
E Vipul está realmente dando un seminario sobre iso hoxe, eu creo que, en 5 horas,
por iso, se pode ir por moito tempo, que sería - 5 ou 4?
Catro. Sentímolo. En realidade, é nada máis iso, entón eu recomendado
unirse ao redor para el se pode.
JQuery é super, super útil, e vai ser capaz de facer unha chea de cousas moi legais con ela
para practicamente calquera proxecto de desenvolvemento web.
>> Agora vou entrar nunha especie de distinción.
Estiven falando basicamente sobre interface de usuario.
UI é só o deseño do sitio web.
Pero hai outro tipo de concepto que é a experiencia do usuario.
Os dous son moi diferentes.
Interface é sempre parte da experiencia.
Noutras palabras, cando vai a un sitio web, mira para a interface.
Isto é parte como experimenta o sitio.
Pero a experiencia do usuario é máis que iso.
A experiencia do usuario é o que a impresión de que o usuario obtén a partir do seu sitio web é.
Entón, obviamente, a interface é unha parte diso.
E é sempre unha parte necesaria, pero non é suficiente.
Noutras palabras, se ten unha interface agradable, e é fermosa e cor e todo iso,
iso é óptimo, pero se o usuario vai para o seu sitio web, ve un esquema fermoso e é confundido por
todo, non ten idea de como facer algo, entón, obviamente, fixo unha realidade
pobre web.
Ese é o tipo de experiencia do usuario onde vén dentro
Vou falar un pouco sobre o proxecto UX - UX é curto para a experiencia do usuario -
e tipo de como pode ter seguro de que ten unha boa experiencia do usuario.
O primeiro punto é que pode crear un sitio onde un usuario pode facer calquera cousa que
que o usuario posiblemente quere.
Pero se o usuario non pode descubrir como facer isto -
noutras palabras, se o usuario non ten unha boa idea cando eles van para a súa web de,
"Oh, se eu queira actualizar o meu perfil, entón eu premer neste botón, ou se eu queira publicar en
mural de alguén, entón eu vou para a súa obra e prema nunha caixinha ".
Se o usuario non sabe diso, entón efectivamente non teñen, de feito,
aplicados correctamente esta funcionalidade.
Parte da implementación dunha función é que os usuarios son realmente capaces de usalo.
E iso pode ser frustrante - que pode facer un sitio, e pode facer todo tipo de
cousas marabillosas, pero despois vai ter xente probalo e dicir: "Non podo facelo.
Por que non pode facer iso? ", E vai dicirlles cara atrás,
"Ben, pode. Vostede só ten que ir ao menú desplegable 7 neste escuro
páxina que só se atopa a unha ligazón na parte inferior dereita man "ou algo así.
Obviamente, non quere iso.
Quere que sexa claro para os usuarios o que eles deben facer,
e debe ser sinxelo e intuitivo para eles.
>> Outra cousa que quere probar facer é, se alguén está indo a ir para a súa web
e 9 de cada 10 veces facer a acción A, e 1 de cada 10 veces facer a acción B,
probablemente vai querer centrar a súa experiencia sobre a acción A.
Noutras palabras, quere facelo moi, moi claro como facer A.
Centro front-e-A debe ser - ir ao sitio web, velo, oh, é logo alí.
Considerando B, obviamente, quere ser claro, pero pode deixar un pouco máis
en segundo plano.
David dá un bo exemplo diso na charla,
que é o sistema de Boston t.
Cando vai para o Boston T e quere mercar un billete,
ten que comezar en 5 menús que poida realmente mercar un billete
para un valor de US $ 2, US $ 2,50, que é o que hai que para andar de metro
nunha dirección.
Isto é un problema porque a maioría das persoas que están camiñando de metro
probablemente só quero ir a un lugar, comprar o seu billete, incorporarse de inmediato.
Non ten sentido que teñen que pasar por unha chea de menús diferentes
para chegar alí.
A mellor experiencia de usuario sería un botón rápido na primeira páxina
que di: "mercar un billete só de ida", e que ía poñer en todos o estándar
valores por omisión, e entón se alguén quere mercar un billete diferente do que iso,
aínda que, por suposto, ten a opción de, pero óptimo para
o caso de uso común que é realmente importante.
Podes ver exemplos diso en Facebook, non?
Se vai para o Facebook e queres publicar un estado,
é ben na parte superior que é o que moitas veces quere facer.
Así que entrar na páxina, pode facer as cousas máis comúns que
quere facer.
Se queres facer as cousas un pouco máis complicadas, como,
dicir que eu quero ir para a parede do meu amigo e publicar unha foto dela -
que eu vou querer facer moitas veces, pero non tan frecuentemente como publicar actualizacións de estado -
Entón, nese caso, eu escribir o seu nome no cadro na parte superior, prema o seu perfil,
e entón, aínda así, é ben na parte superior hai xa que comece o seu perfil.
Unha vez máis, eu óptimo con prioridade para os casos de uso común máis.
>> Outra cousa importante é que moitas veces as persoas van especie de tentar evitar este
dicindo, ok, entón eu fixen o sitio e as persoas están atopando-se confuso,
e iso é un problema, non?
Obviamente, eu non quero que a xente se confunda co contido do meu sitio.
Pero a forma de resolver iso non é ter algo emerxente dicindo:
hey, eu vou ensinalo a usar este sitio.
Paso 1 - prema neste botón. Paso 2 - prema aquí.
Por suposto, iso é un xeito de evitar isto - é un xeito que pode dicir ás persoas o que facer, pero é
realmente non é o camiño ideal.
Se eu fose a un sitio web e de súpeto eu estou bombardeado con este tutorial que está me dicindo
o que facer e onde ir e todo iso, iso non é divertido para min.
Non é unha boa experiencia para min.
É un tipo de dor. Quero só comezar a facer outras cousas.
A xente está indo para pechar a caixa de diálogo,
ou saír do tutorial, non sei que facer, e despois queixa-se porque
non dixen a eles o que facer.
A forma de resolver iso non é dando ningún tipo de tutorial ou direccións -
algo así.
Por máis que se pode evitalo, o que realmente quere amosar ao usuario o que facer
só pola natureza da forma en que o sitio web e colocar para fóra.
Noutras palabras, se eu for a Facebook sen iniciar sesión,
o primeiro que vexo na páxina principal -
é unha pequena caixa de inicio de sesión. Entón, duh. Eu teño para entrar e alí.
Tendo en conta que, se eu fose para Facebook e eu tiña que premer algo ligazón na parte inferior
que dixo 'log in' eo resto da páxina era só unha especie de imaxe ou algo así,
Realmente non sei que facer, non? Quere ser confundido.
Entón, podería dicir-me para ir alí en baixo e prema no botón para iniciar sesión,
ou o rexistro no botón podería ser ben na parte superior, onde eu vou velo.
Quere estar sempre mostrando ao usuario o que facer,
e que debe ser inherente á propia páxina.
>> Cando está a pensar en proxectos e ridiculizando a distintas formas de
expresando o seu sitio, o que realmente quere pensar sobre o que os usuarios están indo a
estar facendo e como pode amosar-lles o que facer.
Unha última cousa é a proba é moi, moi importante.
É gran ter alguén - ter un amigo, peza a alguén que non coñece aínda -
que nunca viu o lugar antes de utilizar o sitio web.
Porque se está a traballar no lugar por horas, que foi mirando para el,
e vostede sabe exactamente o que facer entón, obviamente, vai estar probando o
cousas que traballou e que sabe traballo.
Pero, se alguén vén e usa o sitio web que nunca usou antes,
iso é unha experiencia única, porque ten alguén que non ten coñecemento previo
da web que entra nel, entón eles van ter efectivamente non sabía o que facer
ou que tipo de casos de uso están presentes para eles.
Isto é óptimo. Isto é único, porque son, esencialmente, unha persoa cun espazo en branco para a mente.
Poden dicirlle se algo é confusa ou pouco clara.
Poden lle dar unha idea do que exactamente a experiencia do usuario do seu sitio é.
Pode ser moi difícil dicir que vostede mesmo, entón definitivamente que incentivos-lo
como está a desenvolver os seus proxectos - se está facendo proxectos baseados na web -
para levar a xente a usar o sitio, o máis cedo ten algún tipo de demostración funcional.
>> Agora eu vou falar un pouco sobre como xestionar un proxecto de desenvolvemento web.
Pasamos sobre como pode facer o lado back-end técnico,
como pode crear un sitio moi bo,
e iso é óptimo se está a traballar por si mesmo, pero -
aínda se está a traballar por si mesmo e, sobre todo, se está a traballar nun equipo,
xestión de proxectos tórnase un gran problema.
Xa escoitou falar de tipo de xestión de proxectos en diferentes formas, dende
escola primaria cando lle foi dito o traballo en grupo.
Ten que cooperar, comunicar, todo isto.
Isto todo aínda é aplicable aquí, pero hai algunhas circunstancias únicas con
ciencia da computación que quere estar en conta, e quere estar seguro de tratar ben.
Vou falar primeiro un pouco sobre o equipo que vai estar dentro
É moi importante escoller o tamaño axeitado de un equipo para traballar en,
e no seu proxecto final creo que tes a posibilidade de escoller
entre 1 e 4 persoas, se eu estou correcto.
Quere estar seguro de que non está só escollendo o número de persoas
que quere traballar con eles, porque son os seus amigos.
Quere escoller un equipo que é un bo tamaño e que comezará o traballo feito.
Hai un off comercio de ter máis persoas contra menos persoas.
Se tes máis xente, obviamente, máis traballo se pode facer
porque ten unha morea de xente, unha morea de código, moitas ideas,
e iso é todo gran.
Pero tamén esixe moito máis de xestión e moito máis a comunicación.
Noutras palabras, se ten catro persoas que traballan no mesmo proxecto
e todos eles están a editar o mesmo código, máis ou menos que todo tipo de necesidade de saber
o que está pasando para que require que -
se engadir unha nova función que medio que teño para dicir á xente - estou engadindo este,
Estou cambiando isto desta maneira - especialmente se entrar no cousas realmente profunda
como os modelos e os controladores que están realmente indo para influír o xeito no que o sitio funciona.
Todo o equipo ten que ser consciente de que,
entón tes que asegurarse de que non está escollendo moi grande dun equipo que será difícil
para facer esa comunicación.
Tamén non quere escoller un equipo pequeno abondo para que non vai
poder comunicarse, xa que é só vostede.
>> Outra cousa a considerar é o balance de onde as habilidades das persoas son.
É gran se é realmente todo bos programadores.
Pero se é toda a xente de back-end, a continuación, o seu sitio non vai mirar moi bo
porque ten este gran base de datos, e fai consultas de investigación super-rápido -
o que é óptimo - pero cando vai para el, é como un sitio de 1990 con vermello e azul
en todas as partes, e iso non é bo.
Observe-se que Ben e eu traballando en equipo son moi agradables, porque eu son unha especie de máis
no extremo dianteira, ambos interaccionan no medio-alta, e Ben é realmente bo co material de back-end,
así que funciona moi ben porque podemos proxectar calquera sitio e, basicamente, os buratos
nese sitio que teñen que ser cubertos pode ser cuberto por calquera de nós, ou posiblemente ambos.
Quere estar seguro de que non hai buratos no seu equipo.
Todo ben se hai un pouco de superposición.
Noutras palabras, se ten 2 persoas que son boas con back-end,
que pode ser bo, pero tamén porque poden axudarnos uns a outros con problemas
que están tendo.
Pode ser un problema se só ten unha persoa que é responsable dunha determinada cousa
e se atopan con un problema, entón quere ter un pouco de superposición
pero o máis importante quere estar seguro de que todos os posibles buracos son cubertos.
>> A última cousa - e iso debería ser obvio, pero moitas veces non é.
Quere realmente estar se divertido.
O punto deste proxecto final en CS50 e moitas veces o punto de desenvolvemento web en xeral
non é só para facer un traballo, porque cómpre facer.
Realmente quere divertirse, e quere estar facendo algo
que está motivando a traballar nel.
O que está facendo é unha dor para sentir e traballar,
entón non está escollendo o proxecto correcto.
Quere escoller algo que considerar interesante,
realmente quere ver o resultado, está animado cando comeza unha nova idea sobre
algo que podería facer - polo que hai todo tipo de proxectos alí que eu estou seguro
podes atopar - todo o mundo ten algo que realmente intriga-los
se están facendo un proxecto baseado na web.
Eu vou dicir iso de novo agora.
Se o proxecto parece ser unha dor e non quere traballar con el,
escoller outro proxecto. Escolla algo que realmente che inspira.
>> Ben mencionou ese concepto de iteración algo, e quero pasar por iso un pouco.
É moi importante traballar en chorros onde obter algo funcional.
Pode ser gran se ten este plan a un sitio web que vai facer A, B, e C,
e, finalmente, que vai chegar alí.
Pero está preso nesta fase en que se está a traballar niso e traballar nel,
pero nada está a ser feito. Non ten nada que ver e unha cousa tanxible, funcional.
O que realmente quere facer, tanto como parece un tipo de dor, por veces, a
traballar en algo e logo, tipo de cap-lo para que el sexa polo menos nun cortello, en execución
versión, aínda que non ten todas as características que quere.
E quizais hai algúns recursos que realmente quere engadir, pero simplemente non pode
porque quere obter esta web a un punto funcional.
E así que quere medio que ten todo o proceso de desenvolvemento parecido con iso.
Quere comezar por algún lado funcional - ou esencialmente comezar con nada -
pero quere chegar a algún lugar moi básico e funcional.
E, de novo, facer unha especie de salto e chegar a algún lugar funcional de novo.
Vostede lentamente vai construír, e que podería ir un pouco máis lento do que sería doutra forma,
pero, a longo prazo, se está constantemente preso nesta fase medio termo onde
en realidade, non ten nada de traballo, pode ser realmente unha gran frustración
para traballar no seu proxecto, porque está sempre tan cerca de facelo funcionar,
e nunca realmente traballando.
Quere traballar nestes brotes funcionais,
e tamén quere facer algunha reflexión despois de cada un.
Noutras palabras, cando está nun punto onde o sitio está agora a traballar -
non ten todo o que lle gusta, pero fai algunhas cousas -
quere pensar, todo ben, é neste lugar realizar o obxectivo que me propuxen a facer?
Noutras palabras, se o sitio vai facer X, é o que teño que traballar na dirección de X?
Son todas as características que eu quería alí?
E ademais, é que serve o propósito xeral que quero?
Se pensas que o seu sitio está comezando a virar nunha dirección diferente
ou que as cousas medio que non están funcionando para fóra, pode ser hora de cambiar de marcha un pouco.
Noutras palabras, paga a pena considerar - paga a pena xogar fora ideas, se é necesario
e tendo en conta que eu estou realmente a traballar para o que quero ser.
>> Eu creo que este é o meu próximo punto. Non teña medo de abandonar ideas.
Só porque gastou moitas horas traballando nun recurso
e finalmente teño que traballar, pero realmente non está indo tan ben -
como non é tan útil ou usuarios están a ter problemas para usalo - este tipo de cousas -
Non teña medo de xogar fora.
É unha merda que xa gastou moito tempo traballando niso,
pero ao final non quere un sitio web que é unha especie de elaborada por esas pezas que
tipo de traballo, pero non son moi ben servidos.
Ademais, non teña medo de abrazar novas ideas.
Se alguén vén e di, hey, que o sitio parece moi legal, pero
non sería mesmo moi bo se el tamén fixo iso?
Só porque iso é algo que non tiña a intención e algo que non está no seu
especificacións, algo que non teña a intención de facer,
Non teña medo de asumila e, a continuación, traballar con el.
Porque moitas veces as ideas que executa con todo o curso do desenvolvemento
acaban sendo as características moi legal da web.
>> Eu xa dixen que antes. Eu vou dicir de novo.
Testers son super, super útil.
Probe conseguir que as persoas que nunca viron a páxina antes de facer sesión e ver o que está a suceder
porque non só pode probar a utilidade da web e da experiencia do usuario,
pero eles tamén poden probar a funcionalidade dunha forma que non pode.
Se fai algunha característica que fai unha certa cousa
e vostede sabe que vai facer o mesmo correctamente en cada momento, iso é gran.
Pero moitas veces pode ser difícil de explicar casos de canto, onde A pode usuario
escriba algo que non estaba esperando - precisamente porque marcou
as características de si mesmo.
Así, para que alguén veña de quen non ten idea de como utilizar o sitio web
e só para rompe-lo de todos os xeitos que poden facer é realmente útil, porque
ter unha idea a partir dunha perspectiva totalmente diferente do que o seu sitio está funcionando
eo que ten que arranxar.
>> Por último, vou falar sobre algunhas boas prácticas xerais,
e xa viu unha morea deles en CS50, pero tamén moi, moi aplicar nun ambiente de proxecto.
Un deles é comentarios. Sempre comentar o seu código, especialmente se está a traballar nunha gran equipo.
Ela pode ser tan irritante ter só un bloque xigante de código que alguén está escrito
e quizais funciona, quizais non, pero non ten idea do que fai,
así que non ten idea se é útil ou non, ou se el debe estar alí ou non,
e se está a traballar noutra cousa, é ata posible que estea traballando en
o mesmo, polo que é moi, moi coidado para ser Grazas cos seus compañeiros
e escribir código que é ben documentado.
Non ten que ir tan lonxe a punto de facer a cousa toda que lle gusta, se incrementa
un contador ten un comentario que di, eu estou engadindo 1 a este contador.
Non ten que ser detallada, pero para calquera función que está sempre escribindo
ten que ter algunha documentación sobre o que esta función fai exactamente,
que as súas entradas son, eo que debe retornar.
Desta forma, pode utilizar outros compoñentes do lugar das persoas
e pode traballar no sentido de construír algo grande.
>> Outra cousa importante é que quere facer limpezas regulares.
Código queda confuso. Non se sinta mal se o seu código é só totalmente lexible e unha desorde xigante.
Isto acontece en desenvolvemento web sempre.
Está engadindo novas características, retirando os antigos. Cousas será alí que non debe ser.
Isto é bo, pero quere estar seguro de tratar con isto con regularidade.
Non quere deixar construír ata o punto en que simplemente non pode atopar calquera cousa
no seu código, e non ten idea do que nada fai.
Ese é o caso con HTML.
Ás veces, vai acabar cos obxectos que non conteñen nada,
e quere se librar deles.
En CSS, pode estar referíndose a elementos que non están máis alá,
así que quere se librar dese código.
No JavaScript, pode ter eliminado algo do HTML.
Entón, quere estar seguro de que está sempre limpando, facendo cousas ben
tanto como pode nunha base regular.
>> Outra cousa moi útil que eu non creo que se describe moito na CS50
pero paga a pena metendo e control de versión.
A idea de control de versión é cando está basicamente manter o control de todo o progreso
que fixo a súa web e se nalgún momento entender, oh, este estaba a traballar
hai un tempo, pero non funciona máis, pode volver a versións anteriores
para ver o que cambiou desde entón, e este tipo de cousas.
A principal forma de facelo é co Git, e Git é todo este tipo de sistema que
Creo Tommy MacWilliam deu un seminario sobre o ano pasado.
Se entrar en seminarios CS50 para 2011, se pode ver o seu seminario sobre iso.
A idea do Git é, basicamente, que a regularidade que está facendo eses compromisos
que son formas de dicir o sitio web está nunha versión bastante estable agora, entón
Estou embalar-lo e envialo para lonxe para un servidor, e entón pode ir a ese servidor
e ollar para todas as versións anteriores do seu código e ver como progresou
e todo este tipo de cousas boas.
Entón, é basicamente iso.
Tanto como o desenvolvemento web, estamos felices en ir por aquí e responder a calquera
cuestións, tanto como a nosa presentación.
É iso aí. Grazas. >> [Ben] Grazas.
[Aplausos]
>> [Billy] Persoal, alguén ten algunha dúbida sobre as cousas que nós Cubrimos
ou cousas que non cobren que eles estaban esperando que ía cubrir?
Ficaríamos felices en responder aqueles. Calquera?
[Membro do público] Cales son os pros e contras do uso de Ruby ou Python?
[Ben] A cuestión era, cales son os pros e contras do uso de Ruby ou Python
no canto de como PHP.
As vantaxes son que Ruby e Python son moito mellores que as linguas PHP.
Polo menos na miña opinión, e eu creo que unha morea de opinións doutras persoas tamén.
Eles foron deseñados máis para facer cousas complexas,
e menos a bater xuntos páxinas web moi rápido con
un pouco de contido dinámico.
Os contra son que hai un pouco de - hai máis de unha curva de aprendizaxe
para obtelos creado.
É dicir, como en PHP, pode só ter un ficheiro HTML e escribir menos que,
punto de interrogação, e entón escribir un código, e entón escribir o punto de interrogación,
maior-que, a continuación, está feito.
Noutras linguaxes como Ruby ou Python,
ten que pasar por un pouco máis de traballo para obter o sitio funciona de inicio.
Tamén hai - polo menos adoitaba ser o caso - que hai máis documentación
dispoñible para PHP só porque hai máis persoas a usalo.
Eu creo que non é tanto un problema anymore.
Hai certamente moi boa documentación para cousas como Ruby on Rails
ou Django para Python é o equivalente.
PHP é a que todo o mundo ten usado por anos, e xa sabe como funciona.
Ruby e Python son algo menos maduros.
>> [Membro do público] Se tivese que escoller entre un deles para aprender ou incorporarse,
que prefire?
Honesta, eu creo que depende da persoa.
Sinto moito. A cuestión era o que escolle a alguén a aprender?
Creo Python a máis fermosa persoalmente.
Hai unha gran cantidade de persoas que - eu fixen o meu primeiro proxecto dev web en Python e Django.
Hai unha morea de xente que quere Ruby on Rails tamén.
Probablemente máis persoas souberen Ruby on Rails.
Honesta, quere só de ir con o que a xente ao seu redor saben
para que teña a xente a facer preguntas.
>> A cuestión era - en servidores compartidos é medio difícil de traballar en Python?
Iso depende da súa hospedaxe.
Hai unha serie de provedores de Aloxamento que pode publicar cousas Python.
WebFaction fai iso, non?
WebFaction é aquel que Billy e eu usei para algúns proxectos.
Son realmente grandes. Eles apoian a maioría dos idiomas.
Pero é certo que o PHP é moito máis amplamente soportado.
Entón, se está preso nun servidor que só fai PHP, que é unha boa razón para usar o PHP.
>> [Membro do público] Eu só teño que aprender como consultar algúns bancos de datos,
e sei que o meu SQL está en todo o lugar, pero eu comecei recentemente exposto a -
e apuntou-a para fóra. Ve JSON e bases de datos expansíveis.
My SQL aínda está en todo o lugar. Como ve o que está a suceder?
É que vai haber unha tendencia crecente para máis expansível (inaudível)?
A cuestión era - eu creo que vai ser unha tendencia para as bases de datos non SQL.
Por exemplo, como MongoDB. Coido que é sempre certo.
O meu consello foi principalmente relacionada co MySQL aquí só porque é MySQL
estándar da industria.
Persoalmente, eu prefiro moito máis as bases de datos que non teñen schemos como MongoDB
onde non ten a cuestión de, oh, eu teño engadir outra columna.
¡Ai de min, como todo o que fago?
É moi difícil facelo no MySQL, mais cando ten algo como Mongo
é moito máis agradable.
A outra cousa agradable sobre Mongo é que os seus rexistros son realmente obxectos JavaScript.
Non hai ningún tipo de paso de conversión que precisa para tomar esas liñas de base de datos
e transformalos en un obxecto Javascript e, a continuación, envialos ao longo do fío.
Eu creo que este tipo de cousas vai ser moi, moi útil para o desenvolvemento web rápida no futuro.
>> [Billy] Algo que me gustaría engadir que non é máis que un punto xeral é que
non me sinto como ten que aprender todos os idiomas que discutir
do noso seminario.
Obviamente, o obxectivo é darlle unha idea do que está aí fóra,
e se está intrigado con algunhas das cousas que eu mencionen que podes Google los
e ler sobre eles.
E, como eu mencionen, hai algúns seminarios que tratan precisamente esas cousas.
Hai aínda máis seminarios que eu non teña mencionado que, probablemente, entrar en
isto tamén.
A idea é que, se quere traballar en algo, aquí están as ferramentas á súa disposición.
Non se sente oprimido, se non está realmente certo o que estas ferramentas fan exactamente,
pero sabemos que están aí fóra, e que pode facer uso de ancho deles
por Google.
>> [Membro do público] Que tipo de cousas que debe facer para garantir que o seu sitio web
queda ben en dispositivos móbiles?
[Billy] Os dispositivos móbiles son un pouco difícil.
Hai dúas formas que pode achegarse a el.
A primeira forma é que realmente ten un sitio para móbil.
Noutras palabras, realizar algún tipo de detección, en principio
cando o navegador está a facer a solicitude para a súa web ou que se
voltar este punto de vista - que será o punto de vista para navegadores de escritorio ou portátil -
e este outro punto de vista para dispositivos móbiles.
É un lugar onde as vistas son moi bo no que pode moi ben cambiar o
dous para fóra, e ten unha interfaz que funciona moi ben en dispositivos móbiles
e ter un completamente diferente, que funciona ben en dispositivos navegador.
O problema con isto é que leva moito tempo, porque iso significa codificación
unha interface totalmente diferente.
A outra forma que pode facer é -
unha morea de teléfonos modernos ha amosar sitios e tentar tornalos como un navegador sería,
e eles fan o mellor.
Pode tipo de tentar quedar luz sobre a cantidade de JavaScript jQuery que está a usar
que tende a ser o lugar onde as cousas poden dar mal un pouco.
Esta é unha especie de xeito que pode usar se non ten moito tempo.
Se ten o tempo para traballar nunha interface móbil, que é, obviamente, a súa mellor opción.
>> Eu creo que xeralmente para proxectos de CS50, vai querer escoller un ou outro.
Noutras palabras, quere facer unha aplicación móbil ou se quere facer un sitio de escritorio.
E este tipo de determina onde vai con iso.
Pero se quere expandir-lo máis tarde, probablemente a súa mellor aposta é
para facer unha outra interface para o outro.
Eu teño un pouco de experiencia en desenvolvemento de sitios baseados en WordPress.
I aloxado unha web persoal en WordPress por algún tempo.
Estes tipos de estruturas poden ser agradables cousas tan básicas.
Moitas veces só vai executar nunha serie de preguntas de personalización aínda.
Vai querer ter algo ollar unha determinada maneira ou de ser de certa forma
e simplemente non pode porque é hard-Wired para o sistema que
é así que ten que facer cousas que poden ser un pouco de un problema.
Desde entón eu medio que ser máis inclinado a traballar con sitios a partir de cero.
Para cousas como bases de datos do blog e este tipo de cousas non é realmente tan difícil de construír unha estrutura.
Se está realmente se estendía por vez, pode, por suposto, usar algo como WordPress
ou este tipo de cousas a un blog.
Tipo de cousas que os blogs tenda e non son realmente difíciles o suficiente para que
se está executando en calquera destes tipos de cousas, que é probablemente mellor só
facer unha versión na casa.
>> Eu creo que é sobre iso, entón grazas de novo por vir.
Nós realmente nos gusta de falar con vós e espero que aprendeu algo.
[Ben] Estamos felices en falar - temos a percorrer, pero estamos felices en falar máis do lado de fóra
se ten outra pregunta. Grazas unha vez máis. [Aplausos]
[CS50.TV]