L'histoire

Donc, vous et votre co-fondateur avez cette excellente idée d'entreprise, non?

Vous avez ajouté des fonctionnalités dans votre tête.

Vous demandez souvent leur avis à des clients potentiels et ils adorent tous.

Ok, donc les gens le veulent. Il y a même un peu d'argent à gagner. Et la seule raison pour laquelle ils ne peuvent pas l'obtenir est que vous ne les avez pas encore implémentés.

Puis finalement, vous vous asseyez un jour et vous dites 'Allons-y!' Bientôt, vous essayez de comprendre comment appliquer la logique métier de votre application, la fonctionnalité qui va faire avancer le produit - vous avez une idée de la façon de le faire et vous savez maintenant que vous pouvez le faire.

qu'est-ce qu'un directeur financier en charge de

'C'est fait! Ça marche!' vous dites. Votre preuve de concept est un succès! Il ne reste plus qu'à le regrouper dans une application Web.

«Ok, faisons le site», dites-vous.

Et puis vous réalisez la vérité: vous devez choisir un langage de programmation; vous devez choisir une plate-forme (moderne); vous devez choisir des cadres (modernes); vous devez configurer (et acheter) de l'espace, des bases de données et des fournisseurs d'hébergement; vous avez besoin d'une interface d'administration; vous avez besoin d'un système d'autorisation; vous avez besoin d'un gestionnaire de contenu.

Vous voulez être concis, vous voulez être agile. Vous souhaitez utiliser des technologies qui vous aideront à réussir à court et à long terme. Et ils ne sont pas toujours faciles à choisir

Vous avez des dizaines et des dizaines de décisions architecturales à prendre. Et vous voulez prendre les bonnes: vous voulez utiliser des technologies qui vous permettent un développement rapide, une itération constante, une efficacité maximale, une vitesse, une robustesse et plus encore. Vous voulez être concis, vous voulez être agile. Vous souhaitez utiliser des technologies qui vous aideront à réussir à court et à long terme. Et ils ne sont pas toujours faciles à choisir.

«Je suis débordé», dites-vous, alors que vous vous sentez dépassé. Votre énergie n'est plus la même qu'avant. Vous essayez d'assembler les pièces, mais c'est trop de travail.

Votre preuve de concept se fane et meurt lentement.

La proposition

Après avoir abandonné des tonnes d'idées de cette manière, j'ai décidé de concevoir une solution. Je l'appelle le projet ' Init '(Accueil) (ou init.js).

Le cœur de l'idée est d'avoir un seul projet qui démarre tous les autres, de laisser le développeur ou le fondateur technique prendre ces décisions en même temps et de recevoir un modèle approprié pour commencer en fonction de ces décisions. Je sais ce que les opposants vont dire, 'Une solution ne peut pas s'appliquer à tous les problèmes' (les haineux vont détester). Et ils ont peut-être raison. Mais nous pouvons faire de notre mieux pour créer une solution approximative, et je pense Init est assez proche.

Pour mieux atteindre cet objectif, nous devons garder à l'esprit quelques idées clés. Lorsque je développais Init, j'ai envisagé:

• Composants

  La modularisation est une caractéristique clé de tout système car elle vous permet de réutiliser des composants logiciels dans différents projets - ce qui est l'objectif principal de Init . Mais la modularisation s'accompagne également d'une «remplaçabilité» par produit, qui sera notre meilleur allié lorsqu'il s'agira d'attaquer différents types de problèmes avec «presque» la même solution.

• Facilité de développement

  Pour certains problèmes, il existe quelque part une meilleure solution écrite [Brainf * ck] (https://en.wikipedia.org/wiki/Brainfuck). ou baiser des cerveaux). Mais implémentez cette solution (en Brainf * uck ) serait presque impossible à écrire, encore moins à lire. Cela vous coûterait du temps et des efforts énormes. En général, vous devez utiliser des langages et des plates-formes qui rendent le développement facile et non difficile pour vous (ou pour quelqu'un qui pourra travailler avec plus tard).

• Communauté

  Quelle que soit la plate-forme que vous choisissez, assurez-vous qu'elle a une grande communauté, et une qui peut vous aider avec les problèmes les plus courants et ceux qui ne le sont pas. N'oubliez pas: jQuery n'est peut-être pas le plus rapide , le plus nettoyer , ou le plus chic - mais c'est un gagnant juste à cause de son communauté .

Avec ces objectifs en tête, je vais vous montrer comment j'ai pris mes propres décisions lors de la création Init .

Au fond, Init tire parti de la « JavaScript complet (Certaines personnes se réfèrent à lui, ou à une partie de lui, comme le Pile MOYENNE ). Lorsque vous travaillez avec cet ensemble, Init il est capable d'utiliser une seule langue tout en créant un environnement incroyablement flexible et complet pour le développement d'applications Web. En résumé, Init vous permet d'utiliser JavaScript non seulement pour le développement côté client et serveur, mais également pour la création, les tests, la mise en page, etc.

Mais ralentissons un peu et demandons-nous: JavaScript est-il vraiment une bonne idée?

Pourquoi ai-je choisi JavaScript

Je suis développeur web depuis 1998. A cette époque, nous utilisions Perl pour la plupart de nos développements côté serveur, et même à l'époque, nous avions JavaScript côté client. Les technologies Web côté serveur ont énormément changé depuis lors - nous sommes passés par vague après vague de technologies et de langages différents comme PHP, ASP, JSP, .NET, Ruby, Python, pour n'en nommer que quelques-uns. Les développeurs ont commencé à se rendre compte que l'utilisation de deux langages différents pour les environnements client et serveur compliquait les choses. Les premières tentatives d'unification sous un seul langage essayaient de créer des composants client côté serveur et de les compiler en JavaScript. Cela ne fonctionnait pas comme prévu et beaucoup de ces projets ont échoué (par exemple, ASP MVC remplaçant Formulaires Web ASP.NET , et on pourrait dire que GWT sera remplacé par Polymère ). dans un proche avenir). Mais c'était une excellente idée, en substance: un langage unique sur le client et le serveur, nous permettant de réutiliser des composants et des ressources (c'est la clé: Ressources ).

La réponse était simple: utilisez JavaScript sur le serveur.

lot de ressorts avec botte de ressort

En fait, JavaScript est né avec Côté serveur JavaScript sur Netscape Enterprise Server, mais la langue n'était tout simplement pas prête à l'époque. Après des années d'essais et d'erreurs, Node.js a finalement émergé, ce qui a non seulement mis JavaScript sur le serveur, mais a également promu l'idée de programmation non bloquante , en changeant la façon dont nous écrivons «fread» (I / O) pour toujours (en savoir plus ici .

En une phrase: la planification non bloquante vise à mettre de côté les tâches chronophages, en spécifiant généralement ce qui doit être fait une fois ces tâches terminées et en permettant au processeur de traiter d'autres demandes entre-temps.

Mais ces idées n'étaient pas nouvelles - alors pourquoi sont-elles devenues si populaires avec Node.js? Une programmation simple et non bloquante peut être réalisée de plusieurs manières. Le plus simple est peut-être d'utiliser des rappels et un événement de boucle . Dans la plupart des langages, ce n'est pas une tâche facile: alors que les `` rappels '' sont une fonctionnalité courante dans certains langages, un événement en boucle ne l'est pas, et vous vous retrouvez généralement accroché à des bibliothèques externes (par exemple: Python, avec Tornade ). Mais en JavaScript, rappels sont intégrés dans le langage, ainsi que dans la boucle d'événements, et presque tous les programmeurs qui ont essayé JavaScript les connaissent (ou du moins les ont utilisés, bien que ne comprends pas complètement ce que signifie un événement en boucle ). Soudainement, chacune des startups de la planète Terre pourrait réutiliser des développeurs (par exemple des ressources) à la fois côté client et côté serveur, résolvant le problème 'Guru Python Needed' .

Soudainement, chaque startup sur la planète Terre pourrait réutiliser des développeurs (par exemple des ressources) à la fois du côté client et du côté serveur, résolvant le problème 'Python Guru Needed'.

Alors maintenant, nous avons un plateforme incroyablement rapide (grâce à la programmation non bloquante) avec un langage de programmation incroyablement facile à utiliser (grâce à JavaScript). Mais est-ce suffisant? Cela durera-t-il? Je suis sûr que JavaScript aura une place importante dans le futur. Laissez-moi vous dire pourquoi:

• Programmation fonctionnelle

  JavaScript a été le premier langage de programmation à a dirigé le paradigme fonctionnel aux masses (bien sûr Lisp est venu en premier, mais la plupart des développeurs n'ont jamais construit une application Lisp prête pour une utilisation en production). Lisp et soi, Principales influences Javascript , ils regorgent d'idées innovantes. Ces idées peuvent libérer notre esprit pour explorer de nouvelles techniques, modèles et paradigmes. Et ils mènent tous à JavaScript. Regardez monades , Codage de l'église , ou même (pour un exemple plus pratique) la collection de fonctions] (http://underscorejs.org/#collections), de Underscore.js qui peut vous sauver des lignes et des lignes de code.

• Objets dynamiques et héritage prototypé

  La programmation orientée objet sans classe (et sans les héritages de classe sans fin) permet un développement rapide (créer des objets, ajouter des méthodes et les utiliser) mais, plus important encore, réduit le temps de refactoring pendant les tâches de maintenance en laissant le développeur modifier les instances d'objets au lieu des classes. Cette rapidité et cette flexibilité ouvrent la voie à un développement rapide.

• JavaScript sur Internet

  JavaScript était conçu pour Internet , est ici depuis le début, et ne va pas partir . Toutes les tentatives pour le détruire ont échoué, regardez, par exemple, la chute du Applets Java , le remplacement de VBScript pour Microsoft, TypeScript (qui compilé en JavaScript), et la chute de Flash entre les mains du marché mobile et HTML5. Il est impossible de remplacer Javascript sans casser des millions de pages Web, notre objectif à long terme devrait donc être de l'améliorer. Et il n'y a personne de mieux pour cette tâche que Comité technique 39 par ECMA.

  Ok, des alternatives à JavaScript naissent tous les jours, comment CoffeeScript , Manuscrit , et les les millions de langages qui se compilent en JavaScript . Ces alternatives peuvent être utiles pour les étapes de développement (à travers mappages de code source ), mais ils échoueront à se faire passer pour JavaScript à long terme pour deux raisons: leurs communautés ne seront jamais plus grandes, et leurs meilleures fonctionnalités seront adoptées par le script ECMA (par exemple JavaScript). JavaScript n'est pas comme un langage d'assemblage: c'est un langage de programmation de haut niveau avec un code source que vous pouvez comprendre - alors vous devez le comprendre.

Maintenant, merci à Projet Esprima , vous pouvez créer vos propres outils pour jouer avec le code source, le modifier, changer son style, ajouter des commentaires, de l'instrumentation et toutes sortes de choses que vous pouvez imaginer en jouant avec l'arbre de syntaxe abstraite de votre programme comme si vous jouiez avec une arborescence DOM.

JavaScript de bout en bout: Node.js et MongoDB

Voilà donc les raisons d'utiliser JavaScript. Maintenant, je vais utiliser JavaScript comme raison d'utiliser Node.js et MongoDB.

• Node.js

  Node.js est une plate-forme pour créer des applications réseau rapides et évolutives - c'est essentiellement ce que dit le site Node.js. Mais Node.js est plus que cela: c'est le runtime préféré pour toute application avec un accès aux E / S JavaScript. Même si vous ne prévoyez pas d'écrire votre application serveur principale avec Node.js, vous pouvez utiliser des outils intégrés construits sur Node.js pour améliorer votre processus de développement. Par exemple: Mocha.js pour les tests unitaires, Grunt.js pour les tâches de construction automatisées, ou même Supports pour terminer l'édition du code.

  Donc, si vous envisagez d'écrire des applications JavaScript serveur ou client, vous devez vous familiariser avec Node.js, car vous allez devoir l'utiliser quotidiennement. Il y a des alternatives ), mais aucun d'entre eux n'atteint même 10% de la communauté Node.js.

• MongoDB

  MongoDB c'est une base de données NoSQL basé sur des documents qui utilisent JavaScript comme langage de requête, permettant de compléter de bout en bout la plate-forme JavaScript. Mais ce n'est même pas la raison principale du choix de cette base de données.

  MongoDB est un base de données sans schéma qui permet à vos objets de persister de manière flexible et donc de s'adapter plus rapidement à l'évolution des besoins. En outre, il est fortement évolutif Oui basé sur la réduction de la carte , ce qui le rend adapté aux applications gourmandes en données. MongoDB est si flexible qu'il peut être utilisé comme une base de données de documents sans schéma, un magasin de données relationnelles (bien qu'il manque transactions ), ou même un stockage clé-valeur pour les réponses mises en cache.

Modularisation du serveur avec Express.js

La modularisation côté serveur n'est jamais facile. Mais avec Express.js (O Connect.js ) est venue l'idée de «Middleware» (ou middleware). À mon avis, le middleware est le meilleur moyen de définir les composants sur le serveur. Si vous voulez le comparer à une norme connue, il se rapproche assez des tubes et des filtres.

L'idée de base est que votre composant fait partie d'un tuyau. Le pipeline traite la demande (entrée) et génère une réponse (sortie), mais votre composant n'est pas responsable de la réponse complète. Au lieu de cela, vous modifiez simplement ce dont vous avez besoin, puis déléguez à l'autre morceau de tuyau. Lorsque le dernier morceau de tuyau termine son processus, la réponse est envoyée au client.

Nous appelons ces «morceaux de tuyaux» un «middleware». Clairement, nous pouvons créer deux types de middleware :

• Intermédiaire : Ceux qui traitent la requête et la réponse, mais ne sont pas entièrement responsables de la réponse elle-même, donc ils délèguent au middleware suivant.

• Finales : Ceux qui assument l'entière responsabilité de la réponse finale. Ils traitent et modifient la demande et la réponse, mais ils n'ont pas besoin de déléguer au middleware suivant. En pratique, il est recommandé de déléguer de toute façon à un middleware suivant pour permettre une flexibilité dans l'architecture (par exemple, ajouter plus de middleware plus tard), même si ce middleware n'existe pas (dans ce cas, la réponse ira directement au client)

À titre d'exemple concret, considérons un composant «utilisateur administrateur» sur le serveur. En termes de middleware, nous aurions à la fois des terminaux et des intermédiaires. De notre côté, nous aurions des fonctionnalités telles que la création d'un utilisateur et la liste des utilisateurs. Mais avant de pouvoir effectuer ces actions, nous avons besoin de nos intermédiaires pour l'authentification (puisque nous ne voulons pas que les demandes créent des utilisateurs non authentifiés). Une fois que nous avons créé ces courtiers d'authentification, nous pouvons simplement les brancher partout où nous voulons transformer une fonctionnalité de non-authentification existante en une avec authentification.

Applications d'une seule page

Le projet Init se concentrer sur la création applications d'une seule page (SPAs - Applications d'une seule page) . De nombreux développeurs Web ont été tentés plus d'une fois d'essayer de créer des SPA. J'ai développé en utilisant plusieurs (principalement propriétaires), et je peux affirmer avec certitude qu'ils ne sont que l'avenir des applications Web. Avez-vous déjà comparé un SPA à une application Web classique sur une connexion mobile? La différence de réponse est de plusieurs dizaines de secondes.

Avez-vous déjà comparé un SPA à une application Web classique sur une connexion mobile? La différence de réponse est de plusieurs dizaines de secondes.

Les SPA sont l'avenir du Web - alors pourquoi voudriez-vous fabriquer votre produit sous une forme ancienne? Un argument commun que j'entends est que les gens sont préoccupés par le référencement. Mais si vous gérez correctement les choses, cela ne devrait pas être un problème: Google lui-même a un très bon tutoriel sur la façon de le faire, et il y a de très bons commentaires ici aussi.

MV * côté client avec Backbone.js, Marionette.js et Twitter Bootstrap

On a beaucoup parlé de Framework MVC * pour SPA . C'est une décision compliquée, mais je dirai que les 3 premiers sont Backbone.js , Ember.js , Y Angular.js .

Tous les trois sont bien considérés. Mais lequel d'entre eux est le meilleur pour vous?

Malheureusement, je dois admettre que j'ai une expérience très limitée avec Angular.js, donc je vais le laisser en dehors de cette discussion. Désormais, Ember.js et Backbone.js représentent deux manières différentes d'attaquer le même problème.

Backbone.js il est minimaliste, simpliste et vous offre suffisamment pour créer un SPA simple. D'autre part, Ember.js est un framework entièrement professionnel pour la création de SPA. Il a plus de fioritures, mais aussi une plus grande courbe d'apprentissage.

Selon la taille de votre application, la décision peut être aussi simple que de regarder le ratio fonctionnalités utilisées / fonctionnalités disponibles, ce qui vous donnera un bon indice.

Dans le cas de Init , Je voulais couvrir la plupart des scénarios, j'ai donc choisi Backbone.js pour une création de SPA facile, avec Backbone.Marionette.View pour la modularisation. De cette façon, chaque composant est une application simple et l'application finale peut être aussi complexe que nous le souhaitons.

dans quoi Windows est-il codé

Le style est également un défi, mais nous pouvons, encore une fois, avoir des cadres pour nous sauver. Pour CSS, il n'y a rien de mieux que Bootstrap Twitter , qui offre un ensemble complet de styles prêts à l'emploi et facile à personnaliser .

Booststrap a été créé en utilisant la langue MOINS qui est open source, nous pouvons donc le modifier si nous en avons besoin. Il est livré avec une tonne de contrôles d'utilisabilité qui sont bien documenté sur le site Bootstrap . De plus, il y a un modèle de personnalisation qui vous permet de créer vos propres contrôles. Il est définitivement l'homme pour le poste.

Meilleures pratiques: Grunt.js, Mocha.js, Chai.js, RequireJS et CoverJS

Enfin, nous devons définir certaines de nos meilleures pratiques et examiner comment Init peut vous aider à les implémenter et à les maintenir. Notre solution se concentre sur plusieurs outils, basés sur Node.js.

• Mocha.js et Chai.js :

  Ces outils vous permettent d'améliorer votre processus de développement en appliquant TDD ou BDD , fournissant l'infrastructure pour organiser vos tests unitaires et un lanceur pour les exécuter automatiquement.

  Il y a Milliers des frameworks pour les tests unitaires pour JavaScript. Alors pourquoi utiliser Mocha.js? La réponse courte: il est flexible et complet.

  La réponse longue: il a deux caractéristiques importantes (interfaces, reporters) et une absence importante ( assertions ). Laissez-moi expliquer.

  • Interfaces : Peut-être êtes-vous habitué aux concepts TDD de suites et de tests unitaires, ou peut-être préférez-vous les idées BDD de spécifications de comportement avec ' décrit 'Y' cela devrait ». Mocha.js vous permet d'utiliser les deux approches.
  • Reporters L'exécution de votre test générera des rapports de résultats, et vous pourrez mettre en forme ces résultats à l'aide de différents rapporteurs. Par exemple, si vous devez alimenter un serveur d'intégration continue, vous pouvez trouver un rapporteur pour faire exactement cela.
  • Manque de bibliothèque d'assertions :: loin d'être un problème, Mocha.js a été conçu pour vous permettre d'utiliser la bibliothèque d'assertions de votre choix, offrant plus de flexibilité. Il y a De nombreuses options , mais c'est là que Chai.js entre en jeu.

  Chai.js est une bibliothèque d'assertions flexible qui vous permet d'utiliser l'un des trois styles d'assertions les plus importants:

  • Affirmer : Style d'affirmation classique de la vieille école. Ex.:

    assert.equal(variable, ”valor”);

  • Attendre : Le type d'assertion chaînable le plus couramment utilisé dans BDD. Ex.:

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

  • Devrait : Également utilisé dans BDD, mais je préfère Expect parce que Devrait parce que cela semble répétitif avec la spécification de comportement _'it _ ('devrait faire quelque chose ..' - 'qui devrait faire quelque chose'). Ex.:

    variable.should.equal(“valor”);

  Chai.js se marie parfaitement avec Mocha.js. En utilisant uniquement ces deux bibliothèques, vous pouvez écrire vos tests en TDD, BDD ou tout style imaginable.

• Grunt.js :

  Grunt. UglifyJS ou Compilateur de fermeture ). Vous pouvez ajouter votre propre tâche automatisée à Grunt ou rechercher grognement , où il y a des centaines et des centaines de plugins disponibles (encore une fois, l'utilisation d'outils avec de grandes communautés derrière elle paie bien). Grunt peut aussi surveiller vos fichiers et déclencher des actions lorsqu'elles sont modifiées.

• RequireJS :

  RequireJS peut ressembler à une autre façon de charger des modules avec AMD , mais je peux vous assurer que c'est bien plus que cela. Pour comprendre pourquoi, il faut d'abord évoquer l'idée d'espacement des noms de modules (par exemple, demo.views.hello), qui évite de polluer l'espace de noms global en enveloppant chaque module dans son propre espace de noms. Le problème est que ces modules ne sont pas réutilisables: si vous modifiez l’espace de noms d’une «instance», vous modifiez l’espace de noms de toutes les «instances». Contrairement à cela, RequireJS vous permet de définir des modules réutilisables à partir de zéro. (En outre, cela vous aidera à adopter Injection de dépendance pour empêcher vos modules d'accéder aux variables globales ).

• CouvertureJS :

  Couverture de code c'est une mesure métrique pour évaluer vos tests. Comme son nom l'indique, il vous indique la quantité de code couverte dans votre suite de tests actuelle. CoverJS mesure la couverture de code de vos tests en instrumentant des instructions (au lieu de lignes de code comme JSCoverage ) et générer une version instrumentée de votre code. Il génère également des rapports pour alimenter votre serveur Intégration continue .

Utilisation de _Branches_ (_ramas_) pour basculer entre les fonctionnalités

Quand j'ai commencé Init , J'avais besoin d'un moyen pour les utilisateurs d'activer et de désactiver diverses fonctionnalités qu'ils pourraient souhaiter dans leur projet. J'ai décidé d'adopter une approche radicale avec le système de branchement de git pour implémenter cette fonctionnalité.

En substance, chaque branche représente une fonctionnalité ou une fonctionnalité qu'un utilisateur peut souhaiter inclure. Si vous démarrez un projet à partir de zéro, commencez avec la branche minimale dont vous avez besoin, puis ajoutez d'autres technologies en fusionnant la branche avec les autres de votre choix. Par exemple, disons que vous souhaitez démarrer votre projet avec Backbone.js et Marionette.js. Eh bien, vous pouvez commencer à la branche Backbone.js et la fusionner avec la branche Marionette, en continuant à partir de là pour chaque élément de fonctionnalité que vous souhaitez ajouter.

requêtes multimédias réactives pour tous les appareils

Pour l'instant, l'idée de fusionner pour ajouter des fonctionnalités ne peut être utilisée que pour les modèles technologiques (par exemple, Backbone, Node, Express). Mais à l'avenir, vous pourrez basculer entre les implémentations back-end (par exemple, de MongoDB à Postgres) et côté client.

Démarrez un projet avec Init et déployez-le sur Heroku dès aujourd'hui

Il n'y a jamais eu de moyen plus simple de démarrer un projet. Aller à Dépôt GitHub , vérifiez la branche avec les derniers commits (pour le moment, c'est usermanager, bien que cela puisse changer à l'avenir) et ensuite:

1. Créez un répertoire pour votre projet (ou utilisez-en un existant).
2. Créez votre référentiel avec 'git init' (ou utilisez un référentiel existant)

3. Ajouter un serveur distant avec Init

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

4. Téléchargez la branche de votre choix

   git pull init usermanager

5. Obtenez le fichier de processus Heroku

   git pull init heroku-webprocess

6. Avec lui Ceinture porte-outils Heroku installé, créer une application

   heroku create

7. Poussez la branche principale vers Heroku

   git push heroku master
8. Visitez votre application fonctionnant sur Heroku!

Maintenant, vous pouvez commencer à développer votre fonctionnalité de tueur avec seulement quelques lignes de code. Non seulement cela, mais vous développerez avec les technologies les plus récentes et les plus efficaces dans une suite de développement aussi automatisée que possible.

J'espère que vous pouvez utiliser Init pour commencer votre prochaine excellente idée. N'oubliez pas de consulter le référentiel Init pour les correctifs et les fonctionnalités - son développement est assez actif, et j'ai hâte d'entendre vos commentaires.

Contenu traduit par Pablo Fabregat, membre de TransBunko , un marché des traductions techniques.