[Powered by Google Translate] [Seminário] [Desenvolvimento Web: Da idéia à Implementação] [Ben Kuhn] [Billy Janitsch] [Universidade de Harvard] [Isto é CS50] [CS50.TV] [Billy] Oi, eu sou Billy e este é Ben. >> [Ben] Hi. Nós vamos estar falando sobre desenvolvimento web hoje. [Webdev] [Billy Janitsch e Ben Kuhn] Um pouco sobre nós em primeiro lugar. Ben é o tipo de cara back-end. Ele faz as coisas funcionam. E então eu entrar e fazê-los bonitos. Estou em grande parte envolvida com mais front-end tipo de projeto de layout de coisas, e Ben, por outro lado, sabe o que está fazendo para que ele funciona em coisas back-end. Juntos fizemos algumas coisas. Por exemplo, no ano passado nós trabalhamos em Gimblium que é um estúdio de desenvolvimento de jogos online. Esse era o nosso projeto final para a classe, e desde então fizemos Harvard Classe que é uma estrutura on-line para navegação e cursos de compras em Harvard. 

Vamos começar com essa idéia para o nosso site. Nós vamos fazer o Facebook, mas para gatos. Antes de realmente fazer este site, não fazem este site porque não é bom, mas vamos usá-lo como um quadro e passar pelo processo de como podemos levar esta idéia e transformá-lo em um site real que podemos usar. Vamos começar por quebrar o site para baixo. Como você tem feito no CS50, você quer pensar sobre quais são os componentes reais que vão para o site. Basicamente transformando-o de uma idéia que é apenas uma espécie de um conceito abstrato em uma coisa real e tangível que você poderia fazer. Começamos a fazer algumas perguntas. O que é este site? Por que estamos fazendo isso? O que é que vai ser utilizado? Esse tipo de coisa. No caso do Facebook Gato, que basicamente quer um site que permite que gatos rede social com o outro. A idéia é que eles podem postar em paredes de cada um, eles podem fazer comentários, esse tipo de coisa. E é aí que entramos em componentes funcionais. Temos, agora, este tipo de estrutura de - temos perfis de usuário, temos comentários, e podemos postar. Talvez um dia nós vamos afluente gostos e esse tipo de coisa. E nós meio que quero priorizar esses recursos que vão dentro Queremos dizer como, ok, é muito importante que todos tenham um perfil e que todos possam postar em paredes de cada um. Secundário para que, os comentários seria bom. Talvez mais tarde nós vamos afluente gostos. Então, você quer ter uma idéia do que é fundamental para o seu projeto eo que é uma espécie de característica mais geral que poderia ser aplicado mais tarde. Você quer que a sorte de ter uma lista específica em mente, mas o projeto que você comece com não vai ser o projeto que você terminar com. Em outras palavras, as coisas vão mudar enquanto você está desenvolvendo o site, e você quer deixar espaço para isso. Vou entregá-lo para Ben, que vai falar um pouco sobre a estrutura. 

[Ben] eu vou estar falando sobre o lado mais técnico de desenvolvimento web. Vamos passar por cima de alguns princípios básicos em primeiro lugar. Quando você está fazendo uma aplicação web, a divisão principal que você vai ter que ter é você vai ter alguma coisa acontecendo no lado do cliente - ou seja, o código que você está navegador leva a partir do site eo JavaScript, HTML, CSS coisas. Isso é tudo no lado do cliente. Você vai ter outro código que é executado no lado do servidor que mantém o controle de todos os dados que as pessoas enviam para você, decide quem dar o quê, coisas assim. Este é apenas um pouco de terminologia, de modo que vocês estão familiarizados com o que estamos falando. Além dessa divisão, é bom pensar em sua aplicação web em termos de um par de componentes distintos. Quando você está fazendo desenvolvimento web uma das coisas que você deve estar sempre tentando fazer é reduzir a complexidade. Quanto mais complexo o seu código é o mais chances há de fazer erros, o que é mais difícil mudar mais tarde. Então, se você pode quebrar o seu aplicativo em algumas áreas funcionais distintas que vai - e você pode reduzir o tipo de quantidade de comunicação da área de cross - que irá ajudá-lo muito no longo prazo em termos de redução de bugs. 

Para ser concreto, geralmente as pessoas dividem-se em uma aplicação web - estes são o tipo de palavras da moda agora, mas eles ainda são úteis. Você pode ter ouvido as pessoas falarem sobre modelos, visualizações e controladores. Os modelos são os dados reais que seu aplicativo está indo para lidar com eles. Por exemplo, em seu gato Facebook, seus modelos seria - você teria um modelo para as mensagens como, e um modelo para perfis de usuários, coisas assim. Suas opiniões são como você apresentar esses dados para seus usuários. Você pode ter uma vista para olhar para um único post e todos os comentários e uma visão diferente para sua parede que tem uma lista de todas as mensagens que são direcionados a você, e uma visão diferente para o seu feed de notícias - coisas assim. Finalmente, você tem os controladores que são basicamente quando as pessoas lhe enviar mensagens e você faz atualizações para o sistema de back-end, você incrementa um monte de contadores, e qualquer que seja. Esses são os seus controladores. 

Vou estar falando principalmente sobre os modelos. Visto que não são tecnicamente difíceis e a questão é mais com projetá-los Controladores vão ser específico para o que você está projetando. Mas existem algumas técnicas bastante gerais que você pode usar para fazer seus modelos mais agradável e mais fácil de trabalhar que eu acho que são muito úteis. Isto é principalmente vai ser sobre como lidar com os seus dados aplicativos web de uma forma agradável. Os principais problemas com os modelos são eles que vivem no cliente e no servidor e você tem que descobrir a) como obtê-los - todos os relevantes - a partir do servidor para o cliente, e b) como mantê-los em sincronia. Os usuários vão querer fazer algumas atualizações. Eles vão querer fazer novos posts. Eles vão querer gostar de coisas e coisas, se você tem gostos. Esses são os principais desafios técnicos de lidar com modelos. A primeira coisa que você vai querer perguntar a si mesmo é que tipo de dados vai neste modelo e que tipo de consultas que vamos querer fazer - isto é, como é que vamos olhar para os modelos? Para o seu gato exemplo Facebook, seu post vai ter um autor associado a ele, algum texto pós parede, e um destinatário da mensagem no mural. E então você pode querer consultar que em um monte de maneiras diferentes. Você gostaria de olhar para ele por que escreveu que post, por que recebeu o que postar, talvez pela data em que foram postados. Mas se você está indo fazê-lo por data, então você tem que adicionar outro campo para o seu post de quando foi realmente lançado. Estes dois fatores - o que os dados que você deseja usar e como você deseja vê-lo - você deve pensar sobre eles em primeiro lugar porque eles dependem uns dos outros, e isso vai ser mais difícil para adicioná-los mais tarde. 

Existem algumas outras considerações. Quando você está pensando sobre como você lida com modelos no servidor o que você quer é olhar para - basicamente você quiser fazer o servidor o mais simples possível. Fazer coisas no lado do cliente é geralmente muito mais rápido se você pode fazê-lo apenas no cliente sem fazer qualquer tipo de solicitação de rede. A idéia é fazer o maior número de consultas que puder sobre o cliente. O único problema com que é que se você pedir todos os seus dados no início em seguida, que vai levar um longo tempo para carregar. Então, a idéia é encontrar um meio termo entre ter dados suficientes sobre o cliente que você pode fazer a maioria de seu trabalho lá, mas não apenas buscar tudo de uma vez para que você obtenha os tempos de carregamento muito lento no início. Por exemplo, para o seu gato de dados você provavelmente quer buscar um monte de mensagens de parede recentes. Você não gostaria de pegar todos eles, porque o que poderia dar para trás um par de anos. Mas você não quer buscá-los um de cada vez porque isso iria introduzir uma grande quantidade de sobrecarga da rede. 

Muitas vezes é muito difícil - uma vez que você tem um banco de dados em execução - muitas vezes é muito difícil mudar os dados que você tem nele - ou seja, adicionar uma nova coluna de banco de dados ou algo assim - assim uma boa estratégia é, na verdade, apenas para manter um monte de seus dados em um blob de texto - uma bolha JSON - JSON sendo JavaScript Object Notation - A razão pela qual isso é útil é porque então você pode adicionar novas propriedades a todas estas bolhas JSON sem alterar seu banco de dados. A única desvantagem para isso é que se você tem um monte de campos que você adicionou mais tarde - como escondido em que blob JSON - então é mais difícil de consultá-los dentro do banco de dados. Por exemplo, se você mais tarde - se você teve o seu modelo de post que discutimos anteriormente apenas com o autor, o destinatário eo texto - você também pode ter uma bolha JSON e, em seguida, se mais tarde você quiser adicionar um campo de data você não tem que mudar seu banco de dados. Você poderia apenas adicionar as datas para todos os campos de texto. E então você seria capaz de olhar para aqueles no lado do cliente, mas você não seria capaz de consultá-los no lado do servidor porque está escondido dentro desse texto. 

A outra questão que você quer pensar sobre É assim que o seu cliente e seu servidor vai se comunicar. Você geralmente querem manter este tão simples quanto possível. Você pode apenas ter como um me-get esta solicitação de dados, a criar-a-new-object coisa, e uma solicitação de atualização, um velho-objeto-. E estes seriam todos diferentes URLs em um servidor que você - que o navegador - você pode usar solicitações de AJAX para todos estes e receber ou dados de postagem. Mais uma vez, para o nosso gato exemplo Facebook, você poderia ter a URL para obter uma postagem individual, e você teria uma URL para criar uma nova mensagem no mural e talvez um URL para fazer upload de sua foto do perfil, coisas assim. Mas, novamente, isso é a pré-busca a maioria de seus dados para que você não tem que manter fazer solicitações de rede. Por essa razão, você não pode querer ter essa solicitação get individual para um único post, e em vez disso você só quer uma solicitação get para a parede inteira. E então, se você está tentando encontrar um equilíbrio, porque - isso também vai depender da sua aplicação. Porque se você está esperando que as pessoas têm apenas 10 ou 20 mensagens de parede que vai ficar bem. Mas se você está esperando que eles têm milhares então esse pedido iria demorar muito, e assim que você pode querer adicionar um get-all-mensagens-desde parâmetro. 

Por tudo isso você provavelmente vai querer sincronizar seus dados em JSON - JavaScript Object Notation. Praticamente todas as línguas lida com JSON muito bem. JQuery tem essa função getJSON agradável que vai fazer todo o trabalho duro para você. E no PHP há também muito agradáveis ​​funções de comunicação JSON. Então, isso é provavelmente o melhor formato para o envio de seus modelos e para trás. 

Como um exemplo do que falamos até agora, aqui está um exemplo de fluxo para o seu gato aplicativo do Facebook. Ela começa com o seu navegador solicitando a URL do site base. O servidor provavelmente iria enviar mais de HTML estático e um pouco de JavaScript e CSS. Geralmente é melhor não fazer qualquer processamento no servidor. Você provavelmente não quer - que o servidor não está fazendo lá está indo para baixo a lista de postos de parede e gerar algum código HTML para cada um e de envio que acabou. Geralmente é melhor para fazer isso do lado do cliente, pois caso contrário cada vez que você quiser re-desenhar alguma coisa, você tem que fazer um pedido do servidor. E isso muito rapidamente dá-lhe um monte de cima. Geralmente é melhor só para navio envia HTML estático e, em seguida, JavaScript e CSS que vai fazer a renderização do lado do cliente. Assim que o material chega, então você pode ter - em JavaScript - você pode fazer pedidos para os dados de parede e coisas assim, e depois de que o servidor está basicamente fazendo consultas de banco de dados e verificar as permissões. A única coisa importante é que ele não pode enviar mais alguns outros usuários mensagens de parede que você não tem permissão para ver. Basicamente, pode ser uma camada de acesso a muito fina para o seu banco de dados, e, em seguida, toda a mostrar os dados - todos os pontos de vista e outras coisas - aqueles podem acontecer em seu navegador, e então quando você quer fazer um post ou algo você acabou de enviar um outro pedido. 

Há também algumas coisas extravagantes que você pode fazer em cima disso. Em termos de informações técnicas mais específicas, desenvolvimento em JavaScript simples pode ser um pouco doloroso, por isso há algumas bibliotecas e ferramentas que irão ajudá-lo muito com isso. Eu acho que todos vocês já deve ter ouvido falar sobre jQuery que faz fazer renderização de HTML e manipulação muito mais fácil - tem um monte de funções de fantasia para entrando e saindo, e fazer animações zippy. Há também esta biblioteca chamado Underscore.js. Ele tem um monte de funções de utilidade úteis, coisas que você esperaria JavaScript ter que realmente Doesnt - coisas como embaralhar um array, remoção de duplicatas de uma lista, ou achatamento uma lista de listas. Esta é apenas uma pequena amostra de código. Sublinhado tem uma tonelada dessas funções interessantes que você deseja que você teria todo o tempo. 

E depois há mais uma biblioteca que eu gostaria de passar um pouco de tempo em chamado Backbone.js porque Backbone realmente ajuda a lidar com modelos no lado do cliente e um monte de confusão que isso pode causar. Backbone dá-lhe esse conceito de modelos e coleções em JavaScript que são, basicamente, exatamente como objetos JavaScript em matrizes de JavaScript, mas eles têm eventos quando você muda suas propriedades. Assim como no JavaScript, você pode ter um evento quando um botão é clicado ou algo esses modelos Backbone e coleções Backbone irá transmitir coisas como que quando mudam. Isso significa que você pode simplesmente escrever algo como esse trecho de código aqui - este diz que, sempre que você adicionar qualquer coisa para a matriz mensagens que redesenhar toda a parede. E isto dizer sempre que o número de um posto de gosta de mudanças, você notificar o usuário de que alguém gostou de seu post. Ou sempre que qualquer propriedade de um posto de mudanças que você redesenhar o post. Coisas assim você vai economizar toneladas de complexidade, pois caso contrário se você não tiver algum quadro como este, em seguida, cada vez em seu código que você altere nada sobre um post, você tem que lembrar-se de chamar todas as funções tornam e coisas assim, e se você quiser adicionar algo novo que aconteceu cada vez que você modificou um post que você tem que passar por todos os lugares em sua código que você modificou um post e acrescentar que coisa nova. Uma estrutura como esta vai remover um monte de que a comunicação entre camadas que faz com que seu código complexo e difícil de manter. 

Há um pouco sobre pontos de vista também. Vou deixar a maior parte deste para Billy, porque eles não são tecnicamente muito difícil. Use jQuery para os seus pontos de vista. É praticamente como uma necessidade neste momento. Ele apenas torna tudo muito mais fácil. Há uma grande quantidade de bibliotecas. Se você tiver complicado elementos de interface do usuário, se você quer uma coisa auto-completa ou como uma daquelas multi-seletores de fantasia - se você quiser qualquer coisa assim, você provavelmente deve apenas procurar por aí e você pode encontrar uma boa biblioteca que vai fazer o que você quer. Billy vai explicar mais sobre as partes realmente difíceis de pontos de vista. Além disso, como uma nota lateral, Backbone tem algumas funcionalidades para tornar visualizações comunicar muito bem com modelos - olhar a documentação para todas estas bibliotecas, na verdade. Basta olhar para os docs. Eles são muito bem escrito e fácil de seguir. Em geral, você pode muito bem apenas o Google se você tiver problemas. Há uma grande quantidade de pessoas que os utilizam. Eu acho que isso é como uma nota final. 

Há também algumas coisas mais avançadas que você pode fazer se você está procurando para fazer o seu aplicativo web extra incrível. Você pode fazer - a nova especificação HTML5 tem um monte de coisas extravagantes que você pode fazer. O armazenamento local - o que é que você pode armazenar dados no navegador - ao invés de ter que voltar e ler o servidor para tudo, você pode manter um pouco dele no cliente e que permite que até mesmo pessoas - em alguns casos, pode até mesmo deixá-lo usar a página offline. Não há essa coisa chamada websockets que são um tipo diferente de comunicação de rede onde em vez de apenas lhe fazer um pedido, você recebe a resposta e está feito, você mantenha abrir uma conexão com o servidor e para que você possa fazer coisas como atualizações em tempo real. Então, se você estava tentando fazer um aplicativo de bate-papo, você pode usar websockets para se comunicar e para trás de modo que você não tem que manter a requerente, "Oh, servidor, alguém me enviar um bate-papo?" a cada 10 segundos ou algo assim. Há também um recurso de HTML5 interessante, onde você pode fazer parecer que o URL da página está mudando, sem nunca ter que recarregá-lo. Você pode usar botões Voltar e Avançar sem fazer um monte de pedidos de rede. Coisas como essa é realmente útil em termos de torná-lo rápido, mas também funciona como um aplicativo web deveria. 

Há também uma coisa chamada CoffeeScript. CoffeeScript é uma linguagem diferente, na verdade, que compila para baixo para JavaScript. Você poderia escrever todo o seu código em CoffeeScript, em seguida, executar este compilador, e ele cospe um arquivo JavaScript que você pode incluir em sua página web. A razão que CoffeeScript é bom é porque ele se livrar de um monte de casos estranhos que o JavaScript tem que equivale iguais, e iguais iguais fazer coisas diferentes, ou gosta - ele tem uma sintaxe mais agradável para lidar com matrizes e funções. Este é um pequeno trecho de CoffeeScript que produz uma lista de todas as praças a partir de 10 ^ 2 a 1 ^ 2 na ordem inversa. Como você pode ver, CoffeeScript frequentemente permite-lhe expressar em uma linha o que levaria 5 linhas de JavaScript. Ele pode fazer coisas muito mais fáceis. É um pouco de nova sintaxe para aprender em primeiro lugar, mas definitivamente vai fazer você mais produtivo no longo prazo. 

Você também pode usar outros idiomas no servidor de PHP - linguagens como Ruby, Python, ou há mesmo um projeto chamado node.js que permitirá que você use JavaScript no servidor. Pessoalmente, eu realmente, realmente odeio PHP. Eu só não gosto de trabalhar com ele. Se você também acha que é uma cluge terrível de uma língua, então você pode usar um desses em seu lugar. Em geral, se você quer fazer algo e você realmente não sei como você poderia fazê-lo, basta pesquisar na Internet. Há toneladas e toneladas de recursos, especialmente em - StackOverflow é um grande homem. É o site onde os programadores perguntas uns aos outros. Você pode ter correr para ele, se você estava tendo problemas em conjuntos de problemas CS50. E há toneladas de bibliotecas para fazer praticamente qualquer coisa que você deseja. Se você quiser fazer alguma coisa e você não sabe como fazê-lo, não pense que é impossível. Basta olhar ao redor e você pode encontrar alguns bons recursos. 

Como um general finalizar, os principais delivery são manter as coisas simples. Quanto mais complexo o seu código está no início e quanto mais você tentar e fazer coisas extravagantes, o que levará mais tempo para conseguir algo realmente funcional eo mais difícil será para mudar mais tarde. Então, faça as coisas da maneira burra, fácil primeiro. Para ir junto com isso, não tenha medo de jogar fora código antigo ou limpá-lo muito. Em geral, uma vez que você realmente tem algo de trabalho, é muito mais fácil para pensar que quando você ainda está nos estágios iniciais de como faço para colocar tudo isso junto. É melhor fazer o projeto mais idiota possível que trabalha e então melhorá-lo de forma iterativa do que tentar fazer tudo certo na primeira vez. Em termos de divisão de cliente-servidor, e tentar manter o seu servidor muito simples - apenas um banco de dados e alguns de autenticação e não faço qualquer trabalho duro lá. Faça todas as suas coisas complicadas no lado do cliente no navegador em JavaScript, tanto quanto você puder. Olhe ao redor de bibliotecas que tornam sua vida melhor. Sempre melhor usar o código que alguém escreveu se você - e não para escrevê-lo você mesmo. Há um monte de coisas na Internet. Google é seu melhor amigo. Google é o melhor amigo do programador. Sim, definitivamente não tenha medo de olhar ao redor para outras coisas. Tudo bem. E ao longo de Billy. 

[Billy] Na verdade, antes de eu começar com algumas coisas design, Alguém tem alguma pergunta para Ben sobre qualquer coisa que ele falou? Certo, bom. Mais uma vez, deixe-nos saber se alguma coisa não está claro ou se você gostaria de nos passar por cima de algo um pouco mais. Eu vou voltar um pouco e falar sobre as partes mais fundamentais de design. Ben mencionou o modelo chamado - desculpe, o modelo de sistema de visão controlador que é uma espécie de aspecto técnico, então eu vou olhar a vista, especificamente, e eu vou começar com a forma como você projetar uma visão que parece bom. Aqui é uma espécie de modelo muito básico para o nosso gato Facebook. Eu acho que existem alguns fundamentos em design de interface de usuário moderna que valem a pena pegar. Você pode notar que há um monte de espaço em branco por toda a página, muito espaço para as coisas. Não sinto que você tem para esmagar as coisas em uma página. Você quer deixar muito espaço aberto, e se você for a qualquer website moderno você vai ver que não há branco em todos os lugares. Há branco em lugares que você não esperaria. Você tem essa paleta de cores, e é sábio no início para escolher uma paleta de cores que você vai trabalhar e se desenvolver. Você também - ele ajuda a escolher um tipo de letra, e de que maneira você está tipo de trabalho com estes fundamentos concretos do projeto. Você tem o seu tipo, você tem as suas cores, e então você pode tipo de caber tudo na tão necessária. Então, como eu disse, com seu esquema de cores que deseja usar as cores mais ousadas de seu esquema de cores com moderação. Cabeçalhos são agradáveis. Botões são agradáveis ​​para ter realmente grandes, cores chamativas. Mas, em geral, se você tem um site que tem as cores em todos os lugares, todos olhando na cara, ele só parece confuso, e isso não é bom. Você quer usar geralmente cores claras. Tente, mais uma vez, escolher um esquema de cores muito coerente. Você pode ter estes pequenos salpicos de muita cor - que pode parecer muito bom, mas você quiser usá-los bastante moderação. 

Como eu disse, você quer ser mínima. Menos é sempre mais. Se você pode mostrar alguma coisa ou não apresentar alguma coisa, e você é do tipo sem saber se ele deve estar lá por padrão - provavelmente você é o melhor deixá-la para fora. Você sempre pode adicioná-lo mais tarde. Sim, manter as coisas simples. Mas o mais importante, você quer considerar vários projetos. Não pense que quando você faz um site, você tê-lo em sua cabeça que você vai tornar o site de uma determinada maneira, e ele vai ser exatamente assim. Vai ter o cabeçalho azul na parte superior ea barra lateral azul e então a coisa sub-cabeçalho amarelo. Você quer fazer vários modelos. Você pode - se você é bom com Photo Shop, pode abrir-se e que tipo de criar um site como você gosta de olhar. Se não, você pode apenas usar papel e caneta, mas arranhar-se vários projetos. Você quer ter basicamente um set-up, onde você tem lotes de projetos diferentes, e se alguém acaba de trabalho, então isso é ótimo. Se alguém acaba falhando, então você sempre tem um outro a quem recorrer. Em geral, não se sentem como você deve ser limitado para qualquer projeto que você inicialmente decidir. O design é muito variável, e de parte da importância do modelo sistema de visão controlador é que você pode trocar dentro e fora pontos de vista diferentes que você deseja. Você pode influenciar os dados de uma maneira, e então decidir, oh, na verdade, isso não funciona muito bem. Eu acho que é tipo de muito complicado ou há uma parte aqui que não está realmente trabalhando, então eu só vou abandonar totalmente este ponto de vista e de swap de uma forma totalmente nova. Nós ainda podemos usar os modelos antigos e os antigos controladores. Nós podemos fazer tudo no servidor e cliente como seria antes. Mas a onda real dos dados como apresentado vai ser ligeiramente diferente. 

Quanto realmente implementar o projeto que você quer, uma vez que você tem alguns projetos esboçados em papel ou Photo Shop ou qualquer outra coisa, há uma série de ferramentas que são disponibilizados para você. O primeiro que você está muito familiarizado com o que é seu HTML, PHP, ou qualquer outra coisa linguagem que você está usando apenas para codificar as páginas estáticas em seu site. Você trabalhou muito com HTML, que tipo de dá-lhe estas tags que você pode colocar as coisas em, e, basicamente, é uma forma de organizar o seu conteúdo. Por exemplo, você tem o cabeçalho lá em cima, então você vai ter uma tag de cabeçalho, e ele vai ter um texto dentro dele o que provavelmente vai ser em outra tag. Então você tem uma barra lateral, talvez com alguns links diferentes, e aqueles que vão ser todos em separar as etiquetas. Então, basicamente HTML em seu coração é uma forma de dividir a página como você eventualmente quer formatá-lo. Então, novamente, você já viu isso antes. Você é muito confortável com o trabalho com ele agora uma vez que você fez a última pset esperamos, de modo que não deve ser problema. 

Então você tem CSS que basicamente lida com todos os aspectos de design estáticos. Seria lidar com todas as cores, todos do posicionamento de diferentes elementos, onde se encontram com respeito um ao outro, como eles são grandes, os diferentes tipos de posicionamentos que você teria - em outras palavras, você pode ter as coisas fixas de modo que quando você rolar para baixo eles ficam, ou você pode ter as coisas em relação a outros elementos. Todos esse tipo de coisa é em CSS. Além disso, você pode fazer diferentes decorações, você pode ter as cores do texto, efeitos de texto, todos esse tipo de coisa. Ben deu um bom seminário sobre este último fim de semana, e então eu definitivamente verificar isso, se você pretende estar fazendo algumas coisas extravagantes com CSS. CSS3 é realmente a mais nova versão do CSS, e pode fazer todo tipo de coisas realmente agradáveis. Ele pode fazer gradientes, você pode ter agradáveis, cantos arredondados, você pode fazer todo tipo de coisa para fazer seu site olhar mais moderno e chique. 

A próxima ferramenta é JavaScript e jQuery que Ben falou um pouco sobre, mas eu vou ficar um pouco mais para dentro. JavaScript, como você trabalhou com ele um pouco, ou pelo menos visto em aula, é uma espécie de modo de fazer coisas de forma dinâmica em HTML. HTML, como você sabe, é estático, então quando você tem HTML você não pode modificá-lo. Mas JavaScript, de certa forma, é uma maneira de ser capaz de modificar HTML. Assim, você pode fazer isso, e isso é ótimo, mas JavaScript é realmente uma dor de trabalhar. É tão longo e obtuso e fazer até mesmo as coisas mais simples requer lotes de linhas de JavaScript. Então, jQuery é basicamente uma biblioteca para JavaScript que simplifica tudo isso. Ela diz, tudo bem, se você quer ter uma caixa quadrada vir da esquerda e desaparecer na página para que ele está no meio, em JavaScript que levaria - Eu não sei, cem linhas que fazer, e que seria uma dor, e você sair dela odiando tudo sobre programação web. JQuery você tem basicamente o elemento-dot-fade-in, ou algo assim. Funções Assim, muito, muito simples que permitem que você faça todos os tipos de animações divertidas e esse tipo de coisa. A outra coisa que estes dois são realmente bons para está apenas fazendo coisas dinâmicas com o site. Então, ao invés de apenas ter sua página HTML - que exibe alguns dados, mas na verdade não fazer nada - JavaScript e jQuery vai deixar você tem botões que você pode clicar em, e você pode arrastar elementos e re-forma-los e classificá-los, e ter novos elementos adicionado ou removido. Você pode adicionar-delete, esse tipo de coisa. Então, jQuery faz toneladas de coisas legais. E Vipul está realmente dando um seminário sobre isso hoje, eu acredito que, em 5 horas, por isso, se você pode ficar por muito tempo, que seria - 5 ou 4? Quatro. Desculpe. Na verdade, é logo após isso, então eu recomendaria aderindo ao redor para ele se você pode. JQuery é super, super útil, e você vai ser capaz de fazer um monte de coisas muito legais com ela para praticamente qualquer projeto de desenvolvimento web. 

Agora vou entrar em uma espécie de distinção. Estive falando basicamente sobre interface do usuário. Interface do usuário é apenas o design do site. Mas há outro tipo de conceito que é a experiência do usuário. Os dois são muito diferentes. Interface é definitivamente parte da experiência. Em outras palavras, quando você vai a um site, você olha para a interface. Isso é parte de como você experimenta o site. Mas a experiência do usuário é mais do que isso. A experiência do usuário é sobre o que a impressão de que o usuário obtém a partir de seu site é. Então, obviamente, a interface é uma parte disso. E é definitivamente uma parte necessária, mas não é suficiente. Em outras palavras, se você tem uma interface agradável, e é bonita e colorida e tudo isso, isso é ótimo, mas se o usuário vai para o seu site, vê um layout bonito e ele é confundido por tudo, não tem idéia de como fazer qualquer coisa, então, obviamente, você fez uma realmente pobre website. Esse é o tipo de experiência do usuário onde vem dentro Vou falar um pouco sobre o projeto UX - UX é curto para a experiência do usuário - e tipo de como você pode ter certeza de que você tem uma boa experiência do usuário. O primeiro ponto é que você pode criar um site onde um usuário pode fazer qualquer coisa que que o usuário possivelmente quer. Mas se o usuário não consegue descobrir como fazer essas coisas - em outras palavras, se o usuário não tiver uma boa idéia quando eles vão para o seu site de, "Oh, se eu quiser atualizar o meu perfil, então eu clicar nesse botão, ou se eu quiser postar em mural de alguém, então eu vou para sua parede e clique em uma caixinha. " Se o usuário não sabe disso, então você efetivamente não têm, na verdade, implementados correctamente essa funcionalidade. Parte da implementação de uma funcionalidade é que os usuários são realmente capazes de usá-lo. E isso pode ser frustrante - que você pode fazer um site, e pode fazer todos os tipos de coisas maravilhosas, mas depois você vai ter pessoas testá-lo e dizer: "Não posso fazer isso. Por que ele não pode fazer isso? ", E você vai dizer-lhes para trás, "Bem, pode. Você apenas tem que ir para o menu drop-down 7 neste obscuro página que só é encontrado por um link no canto inferior direito mão "ou algo assim. Obviamente, você não quer isso. Você quer que ele seja claro para os usuários o que eles devem fazer, e ela deve ser simples e intuitivo para eles. 

Outra coisa que você quer tentar fazer é, se alguém está indo para ir para o seu site e 9 em cada 10 vezes fazer a ação A, e 1 em cada 10 vezes fazer a ação B, você provavelmente vai querer centrar a sua experiência sobre a ação A. Em outras palavras, você quer fazê-lo muito, muito claro como fazer A. Centro front-e-A deve ser - ir para o site, vê-lo, oh, é logo ali. Considerando B, obviamente, você quer ser claro, mas você pode deixá-lo um pouco mais em segundo plano. David dá um bom exemplo disso na palestra, que é o sistema de Boston t. Quando você vai para o Boston T e você quer comprar um bilhete, você tem que começar em 5 menus que você possa realmente comprar um bilhete para um valor de US $ 2, US $ 2,50, que é o quanto é preciso para andar de metrô em uma direção. Isso é um problema porque a maioria das pessoas que estão andando de metrô provavelmente só quero ir para um lugar, comprar o seu bilhete, pegar imediatamente. Não faz sentido que eles têm que passar por um monte de menus diferentes para chegar lá. A melhor experiência de usuário seria um botão rápido na primeira página que apenas diz: "comprar um bilhete só de ida", e que iria colocar em todos o padrão valores padrão, e então se alguém quiser comprar um bilhete diferente do que isso, eles ainda, é claro, tem a opção de, mas você otimizado para o caso de uso comum que é realmente importante. Você pode ver exemplos disso no Facebook, certo? Se você vai para o Facebook e você quiser postar um status, é bem no topo que é o que muitas vezes você quer fazer. Assim que você entrar na página, você pode fazer as coisas mais comuns que você quer fazer. Se você quer fazer as coisas um pouco mais complicadas, como, dizer que eu quero ir para a parede do meu amigo e postar uma foto sobre ela - que eu vou querer fazer muitas vezes, mas não tão frequentemente como postar atualizações de status - Então, nesse caso, eu digitar o seu nome na caixa na parte superior, clique no seu perfil, e então, ainda assim, é bem no topo há uma vez que eu comecei ao seu perfil. Mais uma vez, eu otimizado com prioridade para os casos de uso comum mais. 

Outra coisa importante é que muitas vezes as pessoas vão espécie de tentar contornar este dizendo, ok, então eu fiz o site e as pessoas estão encontrando-se confuso, e isso é um problema, certo? Obviamente, eu não quero que as pessoas se confunda com o conteúdo do meu site. Mas a maneira de resolver isso não é ter algo pop-up dizendo: hey, eu vou ensiná-lo a usar este site. Passo 1 - clique neste botão. Passo 2 - clique aqui. Claro, isso é uma maneira de contornar isso - é uma maneira que você pode dizer às pessoas o que fazer, mas é realmente não é o caminho ideal. Se eu for para um site e de repente eu estou bombardeado com este tutorial que está me dizendo o que fazer e para onde ir e tudo isso, isso não é divertido para mim. Não é uma boa experiência para mim. É um tipo de dor. Eu quero apenas começar a fazer outras coisas. As pessoas estão indo para fechar a sua caixa de diálogo, ou sair do tutorial, não sei o que fazer, e depois queixam-se porque você não disse a eles o que fazer. A maneira de resolver isso não é dando qualquer tipo de tutorial ou direções - qualquer coisa assim. Por mais que você pode evitá-lo, você realmente quer mostrar ao usuário o que fazer apenas pela natureza da forma como o site é colocado para fora. Em outras palavras, se eu for para o Facebook sem fazer login, a primeira coisa que eu vejo na página principal - é uma pequena caixa de login. Então, duh. Eu tenho para entrar É ali. Considerando que, se eu fosse para o Facebook e eu tinha que clicar um pouco link na parte inferior que disse 'log in' eo resto da página era apenas uma espécie de imagem ou algo assim, Eu realmente não sei o que fazer, certo? Gostaria de ser confundido. Então, poderia dizer-me para ir lá em baixo e clique no botão para iniciar sessão, ou o registo no botão poderia ser bem no topo, onde eu vou vê-lo. Você quer sempre estar mostrando ao usuário o que fazer, e que deve ser inerente à própria página. 

Quando você está pensando em projetos e ridicularizando-se diferentes formas de expressando seu site, você realmente quer pensar sobre o que os usuários estão indo para estar fazendo e como você pode mostrar-lhes o que fazer. Uma última coisa é o teste é muito, muito importante. É ótimo ter alguém - ter um amigo, peça a alguém que você não conhece ainda - que nunca viu o local antes de utilizar o site. Porque você está trabalhando no local por horas, você foi olhando para ele, e você sabe exatamente o que fazer então, obviamente, você vai estar testando o coisas que você tem trabalhado e que você sabe trabalho. Mas, se alguém vem e usa o site que nunca usou antes, isso é uma experiência única, porque você tem alguém que não tem conhecimento prévio do site que entra nele, então eles vão ter efetivamente não sabia o que fazer ou que tipo de casos de uso estão presentes para eles. Isso é ótimo. Isso é único, porque eles são, essencialmente, uma pessoa com um espaço em branco para a mente. Eles podem lhe dizer se algo é confusa ou pouco clara. Eles podem lhe dar uma idéia do que exatamente a experiência do usuário de seu site é. Pode ser muito difícil dizer que você mesmo, então definitivamente eu incentivá-lo como você está desenvolvendo seus projetos - se você está fazendo projetos baseados na web - para levar as pessoas usando o site, o mais cedo você tem algum tipo de demonstração funcional. 

Agora eu vou falar um pouco sobre como gerenciar um projeto de desenvolvimento web. Passamos sobre como você pode fazer o lado back-end técnico, como você pode criar um site muito bom, e isso é ótimo se você está trabalhando por si mesmo, mas - mesmo se você estiver trabalhando por si mesmo e, especialmente, se você estiver trabalhando em uma equipe, gerenciamento de projetos torna-se um grande problema. Você já ouviu falar sobre tipo de gerenciamento de projetos em diferentes formas, desde escola primária quando lhe foi dito o trabalho em grupo. Você tem que cooperar, comunicar, tudo isso. Isso tudo ainda se aplica aqui, mas existem algumas circunstâncias únicas com ciência da computação que você deseja estar ciente de, e você quer ter certeza de tratar bem. Vou falar primeiro um pouco sobre a equipe que você vai estar dentro É muito importante escolher o tamanho certo de uma equipe para trabalhar em, e em seu projeto final eu acho que você tem a opção de escolher entre 1 e 4 pessoas, se eu estou correto. Você quer ter certeza de que você não está apenas escolhendo o número de pessoas que quer trabalhar com eles, porque são seus amigos. Você quer escolher um time que é um bom tamanho e que vai começar o trabalho feito. Há um off comércio de ter mais pessoas contra menos pessoas. Se você tem mais pessoas, obviamente, mais trabalho pode ser feito porque você tem um monte de gente, um monte de código, muitas idéias, e isso é tudo ótimo. Mas também exige muito mais de gestão e muito mais a comunicação. Em outras palavras, se você tem quatro pessoas que trabalham no mesmo projeto e todos eles estão editando o mesmo código, mais ou menos que todo o tipo de necessidade de saber o que está acontecendo para que ele requer que você - se você adicionar uma nova função que você meio que tenho para dizer às pessoas - estou adicionando este, Eu estou mudando isso dessa maneira - especialmente se você entrar no coisas realmente profunda como os modelos e os controladores que estão realmente indo para influenciar a forma como o site funciona. Toda a equipe precisa estar ciente de que, então você precisa se certificar de que você não está escolhendo muito grande de uma equipe que vai ser difícil para fazer essa comunicação. Você também não quer escolher um time pequeno o suficiente para que você não vai ser capaz de comunicar, porque é só você. 

Outra coisa a considerar é o equilíbrio de onde as habilidades das pessoas são. É ótimo se você é realmente todos os bons programadores. Mas se você é todas as pessoas de back-end, em seguida, o seu site não vai olhar muito bom porque você tem este grande banco de dados, e ele faz consultas de pesquisa super-rápido - o que é ótimo - mas quando você vai para ele, é como um site de 1990 com vermelho e azul em todos os lugares, e isso não é bom. Note-se que Ben e eu trabalhando em equipe são muito agradáveis, porque eu sou uma espécie de mais na extremidade dianteira, ambos interagem no meio-end, e Ben é realmente bom com o material de back-end, assim que funciona muito bem porque nós podemos projetar qualquer site e, basicamente, os buracos nesse site que precisam ser preenchidos pode ser preenchido por qualquer um de nós, ou possivelmente ambos. Você quer ter certeza de que não há buracos em sua equipe. Tudo bem se há um pouco de sobreposição. Em outras palavras, se você tem 2 pessoas que são boas com back-end, que pode ser bom, mas também porque eles podem ajudar uns aos outros com problemas que eles estão tendo. Ele pode ser um problema se você só tem uma pessoa que é responsável por uma determinada coisa e se deparam com um problema, então você quer ter um pouco de sobreposição mas o mais importante quer ter a certeza de que todos os possíveis buracos são preenchidos. 

A última coisa - e isso deveria ser óbvio, mas muitas vezes não é. Você quer realmente estar se divertindo. O ponto deste projeto final em CS50 e muitas vezes o ponto de desenvolvimento web em geral não é apenas para fazer um trabalho, porque ele precisa fazer. Você realmente quer se divertir, e você quer estar fazendo algo que está motivando a trabalhar nele. Se o que você está fazendo é uma dor para sentar e trabalhar, então você não está escolhendo o projeto certo. Você quer escolher algo que você achar interessante, você realmente quer ver o resultado, você está animado quando você começa uma nova idéia sobre algo que você poderia fazer - por isso há todos os tipos de projetos lá que eu tenho certeza você pode encontrar - todo mundo tem algo que realmente intriga-los se eles estão fazendo um projeto baseado na web. Eu vou dizer isso de novo agora. Se o seu projeto parece ser uma dor e você não quer trabalhar com ele, escolher outro projeto. Escolha algo que realmente te inspira. 

Ben mencionou esse conceito de iteração um pouco, e eu quero passar por isso um pouco. É muito importante trabalhar em jorros onde você obter algo funcional. Ele pode ser grande se você tem esse plano para um site que vai fazer A, B, e C, e, eventualmente, ele vai chegar lá. Mas você está preso nesta fase em que você está trabalhando nisso e trabalhar nele, mas nada está sendo feito. Você não tem nada a ver e uma coisa tangível, funcional. O que você realmente quer fazer, tanto quanto parece um tipo de dor, por vezes, a trabalhar em algo e, em seguida, tipo de cap-lo para que ele seja pelo menos em um estábulo, em execução versão, mesmo que ele não tem todas as características que você deseja. E talvez há alguns recursos que você realmente deseja adicionar, mas você simplesmente não pode porque você deseja obter este site a um ponto funcional. E assim que você quer meio que tem todo o processo de desenvolvimento parecido com isso. Você quer começar por algum lado funcional - ou essencialmente começar com nada - mas você quer chegar a algum lugar muito básico e funcional. E, novamente, fazer uma espécie de salto e chegar a algum lugar funcional novamente. Você lentamente vai construir, e que poderia ir um pouco mais lento do que seria de outra forma, mas, a longo prazo, se você está constantemente preso nesta fase meio termo onde na verdade, não tem nada de trabalho, ele pode ser realmente uma grande frustração para trabalhar em seu projeto, porque você está sempre tão perto de fazê-lo funcionar, e ele nunca realmente trabalhando. Você quer trabalhar nestes surtos funcionais, e você também quiser fazer alguma reflexão após cada um. Em outras palavras, quando você está em um ponto onde o site está agora a trabalhar - ele não tem tudo o que você gosta, mas faz algumas coisas - você quer pensar, tudo bem, é neste local realizar o objetivo que me propus a fazer? Em outras palavras, se o site vai fazer X, é o que tenho a trabalhar na direção de X? São todas as funcionalidades que eu queria lá? E além disso, é que serve o propósito geral que eu quero? Se você acha que seu site está começando a virar numa direção diferente ou talvez as coisas meio que não estão funcionando para fora, ele pode ser hora de mudar de marcha um pouco. Em outras palavras, vale a pena considerar - vale a pena jogar fora idéias, se necessário e considerando que eu estou realmente trabalhando para o que eu quero ser. 

Eu acredito que esse é o meu próximo ponto. Não tenha medo de abandonar idéias. Só porque você gastou muitas horas trabalhando em um recurso e, finalmente, tenho que trabalhar, mas ele realmente não está indo tão bem - como não é tão útil ou usuários estão tendo problemas para usá-lo - esse tipo de coisa - Não tenha medo de jogar fora. É uma merda que você já gastou muito tempo trabalhando nisso, mas no final você não quer um site que é uma espécie de elaborada por essas peças que tipo de trabalho, mas não são muito bem servidos. Além disso, não tenha medo de abraçar novas idéias. Se alguém vem e diz, hey, que o site parece muito legal, mas não seria mesmo muito bom se ele também fez isso? Só porque isso é algo que você não tinha a intenção e algo que não está em seu especificações, algo que você não tenha a intenção de fazer, Não tenha medo de assumi-la e, em seguida, trabalhar com ele. Porque muitas vezes as ideias que você executa com todo o curso do desenvolvimento acabam sendo as características muito legal do site. 

Eu já disse isso antes. Eu vou dizer outra vez. Testers são super, super útil. Tente conseguir que as pessoas que nunca viram o site antes de fazer logon e ver o que está acontecendo porque não só pode testar a utilidade do site e da experiência do usuário, mas eles também podem testar a funcionalidade de uma forma que você não pode. Se você fizer alguma característica que faz uma certa coisa e você sabe que ele vai fazer a mesma coisa corretamente a cada momento, isso é ótimo. Mas muitas vezes pode ser difícil de explicar casos de canto, onde A pode usuário digite algo que você não estava esperando - precisamente porque você definiu as características de si mesmo. Assim, para que alguém venha de quem não tem idéia de como usar o site e apenas para quebrá-lo de todas as maneiras que podem fazer é realmente útil, porque você ter uma idéia a partir de uma perspectiva totalmente diferente do que no seu site está funcionando eo que precisa de reparos. 

Por último, vou falar sobre algumas boas práticas gerais, e você já viu um monte deles em CS50, mas também muito, muito aplicar em um ambiente de projeto. Um deles é comentários. Sempre comentar o seu código, especialmente se você está trabalhando em uma grande equipe. Ela pode ser tão irritante ter apenas um bloco gigante de código que alguém está escrito e talvez ele funciona, talvez não, mas você não tem idéia do que ele faz, então você não tem idéia se é útil ou não, ou se ele deve estar lá ou não, e se você estiver trabalhando em outra coisa, é até possível que você esteja trabalhando em a mesma coisa, por isso seja muito, muito cuidado para ser atencioso com os seus pares e escrever código que é bem documentado. Você não tem que ir tão longe a ponto de fazer a coisa toda que gosta, se você incrementa um contador tem um comentário que diz, eu estou adicionando 1 a este contador. Ele não tem que ser detalhada, mas para qualquer função que você está sempre escrevendo você deve ter alguma documentação sobre o que essa função faz exatamente, que suas entradas são, eo que ele deve retornar. Dessa forma, você pode usar outros componentes do local das pessoas e você pode trabalhar no sentido de construir algo grande. 

Outra coisa importante é que você quer fazer limpezas regulares. Código fica confuso. Não se sinta mal se o seu código é apenas totalmente ilegível e uma bagunça gigante. Isso acontece em desenvolvimento web sempre. Você está adicionando novos recursos, retirando os antigos. Coisas vai ser lá que não deve ser. Isso é bom, mas você quer ter a certeza de lidar com isso regularmente. Você não quer deixá-lo construir até o ponto em que você simplesmente não pode encontrar qualquer coisa em seu código, e você não tem idéia do que nada faz. Esse é o caso com HTML. Às vezes, você vai acabar com os objetos que não contêm nada, e você quer se livrar delas. Em CSS, você pode estar se referindo a elementos que não estão mais lá, assim que você quer se livrar desse código. No JavaScript, você pode ter removido algo do HTML. Então, você quer ter certeza de que você está sempre limpando, fazendo coisas bem tanto quanto você pode em uma base regular. 

Outra coisa muito útil que eu não acho que é descrito muito na CS50 mas vale a pena se metendo é controle de versão. A idéia de controle de versão é quando você está basicamente manter o controle de todo o progresso que você fez para seu site e se em algum momento você percebe, oh, este estava trabalhando há um tempo atrás, mas ele não está funcionando mais, você pode voltar para versões anteriores e ver o que mudou desde então, e esse tipo de coisa. A principal maneira de fazer isso é com o Git, e Git é todo este tipo de sistema que Acredito Tommy MacWilliam deu um seminário sobre o ano passado. Se você entrar em seminários CS50 para 2011, você pode ver seu seminário sobre isso. A idéia do Git é, basicamente, que a intervalos regulares que você está fazendo esses compromissos que são formas de dizer o site está em uma versão bastante estável agora, então Estou embalar-lo e enviá-lo para longe para um servidor, e então você pode ir a esse servidor e olhar para todas as versões anteriores do seu código e ver como ele progrediu e todo esse tipo de coisas boas. Então, é basicamente isso. Tanto quanto o desenvolvimento web, estamos felizes em ficar por aqui e responder a qualquer questões, tanto quanto a nossa apresentação. É isso aí. Obrigado. >> [Ben] Obrigado. [Aplausos] 

[Billy] Pessoal, alguém tem alguma dúvida sobre as coisas que nós cobrimos ou coisas que nós não cobrimos que eles estavam esperando que iria cobrir? Ficaríamos felizes em responder aqueles. Qualquer um? [Membro da platéia] Quais são os prós e contras do uso de Ruby ou Python? [Ben] A questão era, quais são os prós e contras do uso de Ruby ou Python em vez de como PHP. As vantagens são que Ruby e Python são muito melhores do que as línguas PHP. Pelo menos na minha opinião, e eu acho que em um monte de opiniões de outras pessoas também. Eles foram projetados mais para fazer coisas complexas, e menos para bater juntos páginas web muito rapidamente com um pouco de conteúdo dinâmico. Os contras são que há um pouco de - há mais de uma curva de aprendizado para obtê-los criado. Ou seja, como em PHP, você pode apenas ter um arquivo HTML e você escrever menos do que, ponto de interrogação, e então você escrever algum código, e então você escrever ponto de interrogação, maior-que, em seguida, você está feito. Em outras linguagens como Ruby ou Python, você tem que passar por um pouco mais de trabalho para obter o site funcionando inicial. Há também - pelo menos costumava ser o caso - que há mais documentação disponível para PHP só porque há mais pessoas a usá-lo. Eu acho que não é tanto um problema anymore. Há certamente muito boa documentação para coisas como Ruby on Rails ou Django para Python é o equivalente. PHP é a que todo mundo tem usado por anos, e você sabe como ele funciona. Ruby e Python são um pouco menos maduros. 

[Membro da platéia] Se você tivesse que escolher entre um deles para aprender ou pegar, qual você prefere? Honestamente, eu acho que depende da pessoa. Sinto muito. A questão era o que você escolheria alguém para aprender? Acho Python a mais bonita pessoalmente. Há uma grande quantidade de pessoas que - eu fiz o meu primeiro projeto dev web em Python e Django. Há um monte de pessoas que gostam de Ruby on Rails também. Provavelmente mais pessoas souberem Ruby on Rails. Honestamente, gostaria apenas de ir com o que as pessoas ao seu redor sabem para que você tenha as pessoas a fazer perguntas. 

A questão era - em servidores compartilhados é meio difícil de trabalhar em Python? Isso depende de sua hospedagem. Há uma série de provedores de hospedagem que irá postar coisas Python. WebFaction faz isso, certo? WebFaction é aquele que Billy e eu usei para alguns projetos. Eles são realmente grandes. Eles apóiam a maioria dos idiomas. Mas é verdade que o PHP é muito mais amplamente suportado. Então, se você está preso em um host que só faz PHP, que é uma boa razão para usar o PHP. 

[Membro da platéia] Eu só tenho a aprender como consultar alguns bancos de dados, e eu sei que meu SQL está em todo o lugar, mas eu comecei recentemente exposto a - e apontou-a para fora. Você vê JSON e bancos de dados expansíveis. My SQL ainda está em todo o lugar. Como você vê o que está acontecendo? É que vai haver uma tendência crescente para mais expansível (inaudível)? A questão era - eu acho que vai ser uma tendência para os bancos de dados não-SQL. Por exemplo, como MongoDB. Eu acho que é definitivamente verdadeiro. Meu conselho foi principalmente relacionada com o mySQL aqui apenas porque é mySQL padrão da indústria. Pessoalmente, eu prefiro muito mais as bases de dados que não têm schemos como MongoDB onde você não tem a questão de, oh, eu preciso adicionar outra coluna. Ai de mim, como tudo o que eu faço? É muito difícil fazer isso no mySQL, mas quando você tem algo como Mongo é muito mais agradável. A outra coisa agradável sobre Mongo é que seus registros são realmente objetos JavaScript. Não há nenhum tipo de passo de conversão que você precisa para tomar essas linhas de base de dados e transformá-los em um objeto JavaScript e, em seguida, enviá-los ao longo do fio. Eu acho que esse tipo de coisa vai ser muito, muito útil para o desenvolvimento web rápida no futuro. 

[Billy] Algo que eu gostaria de acrescentar que é apenas um ponto geral é que não me sinto como você deve ter aprendido todas as línguas que discutimos do nosso seminário. Obviamente, o objetivo é dar-lhe uma idéia do que está lá fora, e se você está intrigado com algumas das coisas que eu mencionei que você pode Google-los e ler sobre eles. E, como eu mencionei, há alguns seminários que tratam precisamente essas coisas. Há ainda mais seminários que eu não tenha mencionado que, provavelmente, entrar em essas coisas também. A idéia é que, se você quer trabalhar em alguma coisa, aqui estão as ferramentas à sua disposição. Não se sente oprimido, se você não está realmente certo o que essas ferramentas fazem exatamente, mas sabemos que eles estão lá fora, e que você pode fazer uso de largura deles pelo Google. 

[Membro da platéia] Que tipo de coisas que você precisa fazer para garantir que o seu site fica bem em dispositivos móveis? [Billy] Os dispositivos móveis são um pouco difícil. Há duas maneiras que você pode se aproximar dele. A primeira maneira é que você realmente tem um site para celular. Em outras palavras, você realizar algum tipo de detecção, no início quando o navegador está fazendo a solicitação para o seu site ou que diz retornar este ponto de vista - que será o ponto de vista para navegadores desktop ou laptop - e este outro ponto de vista para dispositivos móveis. É um lugar onde as vistas são muito bom em que você pode muito bem trocar o dois para fora e tem uma interface que funciona muito bem em dispositivos móveis e ter um completamente diferente, que funciona bem em dispositivos navegador. O problema com isso é que demora muito tempo, porque isso significa codificação uma interface totalmente diferente. A outra maneira que você pode fazer é - um monte de telefones modernos irá exibir sites e tentar torná-los como um navegador seria, e eles fazem o seu melhor. Você pode tipo de tentar ficar luz sobre a quantidade de JavaScript jQuery que você está usando que tende a ser o lugar onde as coisas podem dar errado um pouco. Esta é uma espécie de maneira que você deve usar se você não tem muito tempo. Se você tem o tempo para trabalhar em uma interface móvel, que é, obviamente, a sua melhor opção. 

Eu acho que geralmente para projetos de CS50, você vai querer escolher um ou outro. Em outras palavras, você quer fazer um aplicativo móvel ou se você quiser fazer um site desktop. E esse tipo de determina onde você vai com isso. Mas se você quer expandi-lo mais tarde, provavelmente a sua melhor aposta é para fazer uma outra interface para o outro. Eu tenho um pouco de experiência em desenvolvimento de sites baseados em WordPress. I hospedado um site pessoal em WordPress por algum tempo. Esses tipos de estruturas podem ser agradáveis ​​coisas tão básicas. Muitas vezes você só vai correr em uma série de questões de personalização embora. Você vai querer ter algo olhar uma determinada maneira ou de ser de certa forma e você simplesmente não pode porque ele é hard-wired para o sistema que é assim que você tem que fazer coisas que podem ser um pouco de um problema. Desde então eu meio que sido mais inclinado a trabalhar com sites a partir do zero. Para coisas como bancos de dados do blog e esse tipo de coisa não é realmente tão difícil de construir uma estrutura. Se você está realmente se estendia por vez, você pode, naturalmente, usar algo como WordPress ou esse tipo de coisa para um blog. Os tipos de coisas que os blogs loja e não são realmente difíceis o suficiente para que se você estiver executando em qualquer um desses tipos de coisas, você é provavelmente melhor apenas fazer uma versão em casa. 

Eu acho que é sobre isso, então obrigado novamente por ter vindo. Nós realmente gostamos de falar com vocês e espero que você aprendeu alguma coisa. [Ben] Estamos felizes em falar - temos a percorrer, mas estamos felizes em falar mais do lado de fora se você tem outra pergunta. Obrigado mais uma vez. [Aplausos] [CS50.TV]