A história

Então você e seu cofundador têm essa ótima ideia de negócio, certo?

Você tem adicionado recursos em sua cabeça.

Você freqüentemente pede a opinião de clientes em potencial, e todos eles adoram.

Ok, então as pessoas querem. Ainda há um pouco de dinheiro para ganhar. E a única razão pela qual eles não conseguem é porque você não os implementou - ainda.

Então, finalmente, você se senta um dia e diz 'Vamos lá!' Em breve, você está tentando descobrir como aplicar a lógica de negócios de seu aplicativo, a funcionalidade matadora que impulsionará o produto - você tem uma ideia de como fazer isso e agora sabe que pode fazer isso.

o que é uma estrutura de dados trie

'Feito! Funciona!' você diz. A sua prova de conceito é um sucesso! Tudo o que resta a fazer é empacotá-lo em um aplicativo da web.

'Ok, vamos fazer o site', você diz.

E então você percebe a verdade: você precisa escolher uma linguagem de programação; você precisa escolher uma plataforma (moderna); você precisa escolher alguns frameworks (modernos); você precisa configurar (e comprar) provedores de espaço, banco de dados e hospedagem; você precisa de uma interface de administração; você precisa de um sistema de permissão; você precisa de um gerenciador de conteúdo.

Você quer ser conciso, você quer ser ágil. Você deseja usar tecnologias que o ajudem a ter sucesso a curto e longo prazo. E nem sempre são fáceis de escolher

Você tem dezenas e dezenas de decisões arquitetônicas a tomar. E você quer pegar os corretos: quer usar tecnologias que permitam rápido desenvolvimento, iteração constante, máxima eficiência, velocidade, robustez e muito mais. Você quer ser conciso, você quer ser ágil. Você deseja usar tecnologias que o ajudem a ter sucesso a curto e longo prazo. E nem sempre são fáceis de escolher.

'Estou sobrecarregado', você diz, enquanto parte se sentindo oprimido. Sua energia não é a mesma de antes. Você tenta encaixar as peças, mas dá muito trabalho.

Sua prova de conceito murcha e morre lentamente.

A proposta

Depois de abandonar toneladas de ideias dessa forma, decidi projetar uma solução. Eu chamo isso de projeto ' Iniciar '(Home) (ou init.js).

O cerne da ideia é ter um único projeto que inicie todos os outros, deixar o desenvolvedor ou fundador técnico tomar essas decisões ao mesmo tempo e receber um modelo apropriado para começar com base nessas decisões. Eu sei o que os pessimistas dirão: 'Uma solução não pode ser aplicada a todos os problemas' (os odiadores irão odiar). E eles podem estar certos. Mas podemos tentar o nosso melhor para criar uma solução aproximada, e eu acho Iniciar está perto o suficiente.

Para melhor atingir esse objetivo, temos que manter algumas idéias-chave em mente. Quando eu estava desenvolvendo o Init, eu considerava:

• Componentes

  A modularização é uma característica fundamental de qualquer sistema, pois permite reutilizar componentes de software em diferentes projetos - que é o principal objetivo do Iniciar . Mas a modularização também vem com uma 'substituibilidade' por produto, que será nosso melhor aliado quando se trata de atacar vários tipos de problemas com 'quase' a mesma solução.

• Facilidade de Desenvolvimento

  Para alguns problemas, em algum lugar há uma solução melhor escrita em [Brainf * ck] (https://en.wikipedia.org/wiki/Brainfuck). ou foda-se cérebros). Mas implemente essa solução (em Brainf * uck ) seria quase impossível de escrever, quanto mais de ler. Custaria muito tempo e muito esforço. Em geral, você deve usar linguagens e plataformas que tornem o desenvolvimento fácil e não difícil para você (ou para alguém que possa trabalhar com isso mais tarde).

• Comunidade

  Seja qual for a plataforma que você escolher, certifique-se de que ela tenha uma ótima comunidade e que possa ajudá-lo com os problemas mais comuns e não tão comuns. Lembre-se: jQuery pode não ser o mais rápido , a maioria limpar limpo , ou o mais extravagante - mas é um vencedor apenas por causa de seu comunidade .

Com esses objetivos em mente, vou mostrar como tomei minhas próprias decisões ao criar Iniciar .

Em sua essência, o Init tira proveito do ‘ full-stack JavaScript '(Algumas pessoas se referem a ele, ou uma parte dele, como o MEAN Stack ) Ao trabalhar com este conjunto, Iniciar ele é capaz de usar apenas uma única linguagem enquanto cria um ambiente incrivelmente flexível e completo para o desenvolvimento de aplicativos da web. Em resumo, Iniciar permite que você use JavaScript não apenas para desenvolvimento do lado do cliente e do servidor, mas também para construção, teste, layout e muito mais.

Mas vamos desacelerar um pouco e nos perguntar: o JavaScript é realmente uma boa ideia?

Por que escolhi JavaScript

Sou desenvolvedor web desde 1998. Naquela época, usávamos Perl para a maior parte de nosso desenvolvimento do lado do servidor, e mesmo naquela época, tínhamos JavaScript do lado do cliente. As tecnologias da web do lado do servidor mudaram imensamente desde então - passamos por onda após onda de diferentes tecnologias e linguagens como PHP, ASP, JSP, .NET, Ruby, Python, apenas para citar alguns. Os desenvolvedores começaram a perceber que usar duas linguagens diferentes para ambientes de cliente e servidor estava complicando as coisas. As tentativas iniciais de unificação em uma linguagem tentavam criar componentes de cliente do lado do servidor e compilá-los em JavaScript. Isso não estava funcionando como esperado e muitos desses projetos falharam (por exemplo, substituição de ASP MVC Formulários da web ASP.NET , e pode-se dizer que GWT será substituído por Polímero ) em um futuro próximo). Mas foi uma excelente ideia, no fundo: uma única linguagem no cliente e no servidor, permitindo-nos reutilizar componentes e recursos (esta é a chave: Recursos )

A resposta era simples: use JavaScript no servidor.

Na verdade, o JavaScript nasceu com Lado do servidor JavaScript no Netscape Enterprise Server, mas a linguagem simplesmente não estava pronta na época. Depois de anos de tentativa e erro, Node.js acabou surgindo, o que não só colocou JavaScript no servidor, mas também promoveu a ideia de programação sem bloqueio , mudando a maneira como escrevemos 'fread' (I / O) para sempre (leia mais Aqui .

Em uma frase: o agendamento sem bloqueio visa colocar tarefas demoradas de lado, geralmente especificando o que deve ser feito uma vez que essas tarefas tenham sido concluídas, e permitindo que o processador trate de outras solicitações nesse meio tempo.

Mas essas ideias não eram novas - então por que se tornaram tão populares com o Node.js? A programação simples e sem bloqueio pode ser alcançada de várias maneiras. Talvez o mais fácil seja usar callbacks e um evento de loop . Na maioria das linguagens, essa não é uma tarefa fácil: enquanto 'callbacks' são um recurso comum em algumas linguagens, um evento de loop não é, e você geralmente se pega agarrado a bibliotecas externas (por exemplo: Python, com Twister ) Mas em JavaScript, callbacks são construídos na linguagem, bem como o loop de evento, e quase qualquer programador que se envolveu com JavaScript está familiarizado com eles (ou pelo menos os usou, embora não entendo totalmente o que significa um evento em loop ) De repente, cada uma das startups no Planeta Terra poderia reutilizar desenvolvedores (por exemplo, recursos) tanto no lado do cliente quanto no lado do servidor, resolvendo o problema 'Guru Python necessário' .

como fazer um vidro do google

De repente, cada inicialização no Planeta Terra poderia reutilizar desenvolvedores (por exemplo, recursos) tanto no lado do cliente quanto no lado do servidor, resolvendo o problema 'Python Guru necessário'.

Então agora temos um plataforma incrivelmente rápida (graças à programação sem bloqueio) com uma linguagem de programação incrivelmente fácil de usar (graças ao JavaScript). Mas é o suficiente? Isso vai durar? Tenho certeza de que o JavaScript terá um lugar importante no futuro. Deixa-me dizer-te porquê:

• Programação funcional

  JavaScript foi a primeira linguagem de programação a liderou o paradigma funcional para as massas (é claro que o Lisp veio primeiro, mas a maioria dos desenvolvedores nunca construiu um aplicativo Lisp pronto para uso em produção). Lisp e Self, Principais influências do Javascript , eles estão cheios de ideias inovadoras. Essas idéias podem liberar nossas mentes para explorar novas técnicas, padrões e paradigmas. E todos eles levam ao JavaScript. Veja mônadas , Codificação da igreja , ou mesmo (para um exemplo mais prático) a coleção de funções] (http://underscorejs.org/#collections), de Underscore.js que pode economizar linhas e linhas de código.

• Objetos Dinâmicos e Herança Prototipada

  A programação orientada a objetos sem classes (e sem as heranças de classes infinitas) permite o desenvolvimento rápido (criar objetos, adicionar métodos e usá-los), mas, o mais importante, reduz o tempo de refatoração durante as tarefas de manutenção, permitindo que o desenvolvedor modifique instâncias de objetos em vez de classes. Essa velocidade e flexibilidade abre caminho para um rápido desenvolvimento.

• JavaScript it internet

  JavaScript era projetado para a internet , está aqui desde o início e não vai sair . Todas as tentativas de destruí-lo falharam, veja, por exemplo, a queda do Applets Java , a substituição do VBScript para Microsoft, TypeScript (que compilou para JavaScript), e a queda do Flash nas mãos do mercado móvel e HTML5. É impossível substituir o Javascript sem quebrar milhões de páginas da web, portanto, nosso objetivo de longo prazo deve ser melhorá-lo. E não há ninguém melhor para essa tarefa do que Comitê Técnico 39 pela ECMA.

  Ok, alternativas ao JavaScript nascem todos os dias, como CoffeeScript , TypeScript , e os os milhões de linguagens que compilam para JavaScript . Essas alternativas podem ser úteis para estágios de desenvolvimento (por meio de mapeamentos de código fonte ), mas eles não conseguirão personificar o JavaScript no longo prazo por dois motivos: suas comunidades nunca serão maiores e sua melhor funcionalidade será adotada pelo script ECMA (por exemplo, JavaScript). JavaScript não é como uma linguagem assembly: é uma linguagem de programação de alto nível com código-fonte que você pode entender - então você deve entender.

Agora, graças a Projeto Esprima , você pode criar suas próprias ferramentas para brincar com o código-fonte, modificando-o, mudando seu estilo, adicionando comentários, instrumentação e todos os tipos de coisas que você pode imaginar ao brincar com a Árvore de Sintaxe Abstrata do seu programa como se estivesse jogando com uma árvore DOM.

JavaScript ponta a ponta: Node.js e MongoDB

Então, essas são as razões para usar JavaScript. Agora, vou usar JavaScript como um motivo para usar Node.js e MongoDB.

• Node.js

  Node.js é uma plataforma para construir aplicativos de rede rápidos e escalonáveis ​​- é basicamente isso que o site Node.js diz. Mas o Node.js é mais do que isso: é o runtime preferido para qualquer aplicativo com acesso de E / S de JavaScript. Mesmo se você não planeja escrever seu aplicativo de servidor principal com Node.js, você pode usar ferramentas integradas construídas sobre Node.js para melhorar seu processo de desenvolvimento. Por exemplo: Mocha.js para teste de unidade, Grunt.js para tarefas de construção automatizadas, ou mesmo Colchetes para concluir a edição do código.

  Portanto, se você for escrever aplicativos JavaScript de servidor ou cliente, deve se familiarizar com o Node.js, porque precisará usá-lo diariamente. Existem alguns interessantes alternativas ), mas nenhum deles chega a nem mesmo 10% da comunidade Node.js.

• MongoDB

  MongoDB é um banco de dados NoSQL baseado em documentos que usam JavaScript como sua linguagem de consulta, permitindo a conclusão de ponta a ponta da plataforma JavaScript. Mas esse nem é o principal motivo para escolher este banco de dados.

  MongoDB é um banco de dados sem esquema que permite que seus objetos persistam de maneira flexível e, portanto, se adaptem mais rapidamente aos requisitos em mudança. Além disso, é altamente escalável Y baseado em redução de mapa , o que o torna adequado para aplicativos com muitos dados. O MongoDB é tão flexível que pode ser usado como um banco de dados de documentos sem esquema, um armazenamento de dados relacional (embora falte transações ), ou mesmo armazenamento de valor-chave para respostas em cache.

Modularização do servidor com Express.js

A modularização no lado do servidor nunca é fácil. Mas com Express.js (Y Connect.js ) surgiu a ideia de ‘Middleware’ (ou middleware). Na minha opinião, o middleware é a melhor forma de definir componentes no servidor. Se você quiser compará-lo a um padrão conhecido, ele chega bem perto de tubos e filtros.

A ideia básica é que seu componente faça parte de um tubo. O pipeline processa a solicitação (entrada) e gera uma resposta (saída), mas seu componente não é responsável pela resposta completa. Em vez disso, você apenas modifica o que precisa e então delega para o outro pedaço de tubo. Quando o último pedaço de tubo termina seu processo, a resposta é enviada ao cliente.

Nós nos referimos a essas 'peças tubulares' como 'middleware'. Claramente, podemos criar dois tipos de middleware :

• Intermediário : Aqueles que processam a solicitação e a resposta, mas não são totalmente responsáveis ​​pela resposta em si, então eles delegam ao próximo middleware.

• Finais : Aqueles que assumem total responsabilidade na resposta final. Eles processam e modificam a solicitação e a resposta, mas não precisam delegar para o próximo middleware. Na prática, é recomendável que você delegue a um próximo middleware de qualquer maneira para permitir flexibilidade na arquitetura (por exemplo, adicione mais middleware posteriormente), mesmo se esse middleware não existir (nesse caso, a resposta irá diretamente para o cliente)

Como um exemplo concreto, considere um componente 'usuário administrador' no servidor. Em termos de middleware, teríamos terminais e intermediários. No nosso final, teríamos recursos como criar um usuário e listar usuários. Mas antes de podermos realizar essas ações, precisamos de nossos intermediários para autenticação (já que não queremos solicitações para criar usuários não autenticados). Depois de criar esses brokers de autenticação, podemos simplesmente conectá-los em qualquer lugar que quisermos para transformar um recurso de não autenticação existente em um com autenticação.

o que é um designer visual

Aplicativos de página única

O projeto Iniciar foco na criação aplicativos de página única (SPAs-aplicativos de página única) . Muitos desenvolvedores da web foram tentados mais de uma vez a tentar construir SPAs. Desenvolvi usando vários (principalmente proprietários), e posso dizer com segurança que eles são simplesmente o futuro das aplicações web. Você já comparou um SPA a um aplicativo da web comum em uma conexão móvel? A diferença na resposta é de dezenas de segundos.

Você já comparou um SPA a um aplicativo da web comum em uma conexão móvel? A diferença na resposta é de dezenas de segundos.

SPAs são o futuro da web - então por que você faria seu produto em uma forma antiga? Um argumento comum que ouço é que as pessoas estão preocupadas com o SEO. Mas se você lidar com as coisas corretamente, isso não deve ser um problema: o próprio Google tem um tutorial muito bom sobre como fazer, e há comentários muito bons Aqui também.

MV * do lado do cliente com Backbone.js, Marionette.js e Twitter Bootstrap

Muito se tem falado sobre Frameworks MVC * para SPAs . É uma decisão complicada, mas direi que os 3 primeiros são Backbone.js , Ember.js , Y Angular.js .

Todos os três são bem vistos. Mas qual deles é o melhor para você?

Infelizmente, tenho que admitir que tenho uma experiência muito limitada com Angular.js, então vou deixá-lo fora desta discussão. Agora, Ember.js e Backbone.js representam duas maneiras diferentes de atacar o mesmo problema.

Backbone.js é minimalista, simplista e oferece o suficiente para criar um simples SPA. Por outro lado, o Ember.js é uma estrutura totalmente profissional para a criação de SPAs. Tem mais babados, mas também uma curva de aprendizado maior.

Dependendo do tamanho do seu aplicativo, a decisão pode ser tão fácil quanto olhar a proporção de featuresUsed / featuresAvailable, o que lhe dará uma ótima pista.

Em caso de Iniciar , Eu queria cobrir a maioria dos cenários, então escolhi Backbone.js para criação fácil de SPA, com Backbone.Marionette.View para modularização. Dessa forma, cada componente é um aplicativo simples e o aplicativo final pode ser tão complexo quanto desejarmos.

O estilo também é um desafio, mas podemos, novamente, ter frameworks para nos resgatar. Para CSS, não há nada melhor do que Twitter Bootstrap , que oferece um conjunto completo de estilos prontos para uso e fácil de personalizar .

Booststrap foi criado usando a linguagem MENOS que é de código aberto, para que possamos modificá-lo se precisarmos. Ele vem com uma tonelada de controles de usabilidade que são bem documentado no site Bootstrap . Além disso, há um modelo de customização que permite a você criar seus próprios controles. Ele é definitivamente o homem certo para o trabalho.

Práticas recomendadas: Grunt.js, Mocha.js, Chai.js, RequireJS e CoverJS

Finalmente, devemos definir algumas de nossas melhores práticas e ver como o Init pode ajudá-lo a implementá-las e mantê-las. Nossa solução está focada em diversas ferramentas, que são baseadas em Node.js.

• Mocha.js e Chai.js :

  Essas ferramentas permitem que você melhore seu processo de desenvolvimento aplicando TDD ou BDD , fornecendo a infraestrutura para organizar seus testes de unidade e um inicializador para executá-los automaticamente.

  tem Milhares de estruturas para testes de unidade para JavaScript. Então, por que usar Mocha.js? A resposta curta: é flexível e abrangente.

  A resposta longa: tem duas características importantes (interfaces, repórteres) e uma ausência importante ( afirmações ) Deixe-me explicar.

  • Interfaces : Talvez você esteja acostumado com os conceitos de TDD de suítes e testes de unidade, ou talvez você prefira ideias BDD de especificações de comportamento com “ descreve 'Y' deveria ”. Mocha.js permite que você use ambas as abordagens.
  • Repórteres A execução do seu teste gerará relatórios de resultados e você pode formatar esses resultados usando vários repórteres. Por exemplo, se você tiver que alimentar um servidor de Integração Contínua, poderá encontrar um relator para fazer exatamente isso.
  • Falta de uma biblioteca de afirmações :: longe de ser um problema, o Mocha.js foi projetado para permitir que você use a biblioteca de asserções de sua escolha, oferecendo mais flexibilidade. tem Muitas opções , mas é aí que o Chai.js entra em jogo.

  Chai.js é uma biblioteca de asserções flexível que permite usar qualquer um dos três estilos mais importantes de asserções:

  • Afirmar : Estilo clássico de afirmação da velha escola. Ex .:

    assert.equal(variable, ”valor”);

  • Espero : O tipo de asserção encadeada mais comumente usado no BDD. Ex .:

    problemas e soluções de segurança cibernética

    expect(variable).to.equal(“valor”);

  • Devemos : Também usado no BDD, mas prefiro Expect porque deveria porque parece repetitivo com a especificação de comportamento _'it _ ('deve fazer algo ..' - 'isso deve fazer algo'). Ex .:

    variable.should.equal(“valor”);

  Chai.js combina perfeitamente com Mocha.js. Usando apenas essas duas bibliotecas, você pode escrever seus testes em TDD, BDD ou qualquer estilo imaginável.

• Grunt.js :

  Com UglifyJS ou Compilador de Fechamento ) Você pode adicionar sua própria tarefa automatizada ao Grunt ou pesquisar o registro de grunhido , onde há centenas e centenas de plug-ins disponíveis (novamente, usar ferramentas com grandes comunidades por trás disso paga bem). Grunt também pode monitore seus arquivos e acionar ações quando forem modificados.

• RequireJS :

  RequireJS pode soar como outra maneira de carregar módulos com AMD , mas posso garantir que é muito mais do que isso. Para entender por quê, devemos primeiro mencionar a ideia de namespacing do módulo (por exemplo, demo.views.hello), que evita poluir o namespace global envolvendo cada módulo em seu próprio namespace. O problema é que esses módulos não são reutilizáveis: se você modificar o namespace de uma 'instância', estará modificando o namespace de todas as 'instâncias'. Em contraste com isso, RequireJS permite definir módulos reutilizáveis ​​do zero. (Além disso, vai ajudá-lo a adotar Injeção de dependência para evitar que seus módulos acessem variáveis ​​globais )

• CoverJS :

  Cobertura de código é uma medida métrica para avaliar seu teste. Como o nome indica, ele informa quanto código é coberto em seu conjunto de testes atual. CoverJS mede a cobertura de código de seus testes instrumentando instruções (em vez de linhas de código como JSCoverage ) e gerar uma versão instrumentada de seu código. Ele também gera relatórios para alimentar seu servidor integração contínua .

Usando _Branches_ (_ramas_) para alternar recursos

Quando eu comecei Iniciar , Eu precisava de uma maneira para que os usuários ativassem e desativassem vários recursos que eles desejam em seus projetos. Decidi adotar uma abordagem radical com o sistema de ramificação do git para implementar essa funcionalidade.

Em essência, cada ramificação representa um recurso ou funcionalidade que um usuário pode querer incluir. Se você está começando um projeto do zero, comece com o branch mínimo de que precisa e, em seguida, adicione outras tecnologias mesclando o branch com as outras desejadas. Por exemplo, digamos que você deseja iniciar seu projeto com Backbone.js e Marionette.js. Bem, você pode começar no branch Backbone.js e mesclá-lo com o branch Marionette, continuando a partir daí para cada parte da funcionalidade que deseja adicionar.

Por enquanto, a ideia de mesclar para adicionar funcionalidade só pode ser usada para modelos de tecnologia (por exemplo, Backbone, Node, Express). Mas, no futuro, você será capaz de alternar entre back-end (por exemplo, de MongoDB para Postgres) e implementações do lado do cliente.

Comece um projeto com Init e implante no Heroku hoje

Nunca houve uma maneira mais fácil de iniciar um projeto. Vamos para Repositório GitHub , verifique o branch com os últimos commits (agora é usermanager, embora isso possa mudar no futuro) e então:

1. Crie um diretório para o seu projeto (ou use um existente).
2. Crie seu repositório com 'git init' (ou use um repositório existente)

3. Adicionar um servidor remoto com Init

   git remote add init git: //github.com/picanteverde/init.git

4. Baixe o branch que você deseja

   git pull init usermanager

5. Obtenha o arquivo de processo do Heroku

   git pull init heroku-webprocess

6. Com ele Heroku Toolbelt instalado, crie um aplicativo

   heroku create

7. Empurre o branch master para Heroku

   git push heroku master
8. Visite seu aplicativo em execução no Heroku!

Agora você pode começar a desenvolver seu recurso matador com apenas algumas linhas de código. Além disso, você estará desenvolvendo com as tecnologias mais recentes e eficientes em um pacote de desenvolvimento o mais automatizado possível.

Espero que você possa usar Iniciar para iniciar sua próxima grande ideia. Lembre-se de verificar o repositório Init para correções e recursos - seu desenvolvimento é bastante ativo e estou ansioso para ouvir seus comentários.

Conteúdo traduzido por Pablo Fabregat, sócio de TransBunko , um mercado de traduções técnicas.