L'histoire

Donc, vous et votre partenaire avez eu cette excellente idée d'entreprise, non?

Vous avez ajouté des fonctionnalités au système mentalement.

Vous demandez souvent aux clients potentiels ce qu'ils pensent, et ils adorent tous.

vr/ar/mr

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

Alors vous vous asseyez enfin un jour et vous dites: 'Faisons ça!' Vous essayez donc de comprendre comment implémenter la logique métier de votre application, la fonctionnalité qui fera avancer le produit: vous avez une idée de comment le faire et vous vous connaissez pouvez faire.

'Terminé! Ça marche! », Dites-vous. Votre preuve de concept est un succès! Il ne manque que l'empaquetage dans une application Web.

'Ok, créons le site Web', dites-vous.

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

Vous voulez que ce soit léger, 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 décisions: vous voulez utiliser des technologies qui permettent un développement rapide, une itération constante, une efficacité, une vitesse, une robustesse maximales, etc. Vous voulez que ce soit léger, 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, vous sentant vraiment dépassé. Votre énergie n'est plus la même. Vous essayez d'assembler les pièces, mais c'est trop de travail.

Votre preuve de concept sèche lentement et meurt.

La proposition

Après avoir moi-même abandonné d'innombrables idées, j'ai décidé de construire une solution. J'appelle ça un projet ' Init »(Ou, init.js).

La partie centrale de l'idée est d'avoir un seul projet pour tout démarrer, pour permettre au développeur ou au fondateur technique de prendre toutes ces décisions essentielles en même temps, et de recevoir un modèle base initiale appropriée sur la base de ces décisions. Je sais ce que diront les détracteurs: 'une solution ne peut pas être appliquée à toutes sortes de problèmes' (les haineux détesteront). Et ils peuvent avoir raison. Mais nous pouvons faire de notre mieux pour créer une solution appropriée, et je pense qu'Init s'en rapproche.

Pour mieux atteindre cet objectif, nous devons garder certaines idées à l'esprit. Lors du développement d'Init, j'ai envisagé:

• Composants

  La mise en composants est une caractéristique clé de tout système car elle permet la réutilisation de composants logiciels dans différents projets - ce qui est l'objectif principal d'Init. Mais la mise en composants s'accompagne également d'un sous-produit, «l'interchangeabilité», qui sera notre meilleur allié pour résoudre plusieurs problèmes différents avec «presque» la même solution.

• Facilité de développement

  Pour tout problème, est-ce que quelqu'un a une meilleure solution écrite en Brainf * ck . Mais la mise en œuvre de cette solution (dans Brainfuck) sera pratiquement impossible à écrire, encore moins à lire. Cela vous coûtera du temps et des efforts considérables. En général, vous devez utiliser des langages et des plates-formes qui facilitent le développement, pas plus difficile pour vous (ou pour quiconque pourrait y travailler plus tard).

• Communauté

  Quelle que soit la plate-forme que vous choisissez, assurez-vous d'avoir une grande communauté, et une qui peut vous aider avec les problèmes les plus courants et inhabituels. Rappelez-vous: jQuery n'est peut-être pas la bibliothèque Plus vite , nettoyeur , ou plus élégant - mais c'est un gagnant simplement en raison de son communauté .

En gardant ces objectifs à l'esprit, je vais vous montrer comment j'ai pris mes décisions lors de la création d'Init.

Au fond, l’Init tire parti du «paradigme» JavaScript complet Paradigme (certaines personnes y font référence, ou un sous-ensemble de celui-ci, comme le Pile MOYENNE ). Lorsque vous travaillez avec une telle pile, Init est capable d'utiliser un seul langage tout en créant un environnement incroyablement flexible et riche en fonctionnalités pour le développement d'applications Web. En bref, il vous permet d'utiliser JavaScript non seulement pour le développement de clients et de serveurs, mais également pour la construction, les tests, la création de modèles, etc.

Mais ralentissons un instant et demandons-nous: est-ce vraiment une bonne idée d'utiliser JavaScript?

Pourquoi j'ai choisi JavaScript

Je suis développeur web depuis 1998. Là-bas, nous avons utilisé Perl pour la plupart des développements côté serveur, mais même dans ce cas, nous avons eu JavaScript côté client. Depuis lors, les technologies pour les serveurs Web ont énormément changé: nous sommes passés vague après vague de langages et de technologies tels que 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 langues différentes pour les environnements client et serveur compliquait les choses. Les premières tentatives d'unification sous un seul langage visaient à créer des composants clients sur le serveur et à les compiler pour JavaScript. Cela n'a pas fonctionné comme prévu et la plupart des projets ont échoué (par exemple: remplacement d'ASP MVC Formulaires Web ASP.NET , est GWT sans doute être remplacé dans un proche avenir par Polymère ). Mais c'était une excellente idée: un langage unique sur le client et sur le serveur, nous permettant de réutiliser des composants et des ressources (c'est le mot clé: Ressources ).

La réponse était simple: placez JavaScript et non le serveur.

JavaScript [est né avec JavaScript Server Side] (http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969) sur Netscape Enterprise Server, mais le langage n'était tout simplement pas prêt À ce moment-là. Après des années d'essais et d'erreurs, le Node.js a finalement émergé, qui a non seulement mis JavaScript sur le serveur, mais a également promu l'idée de programmation non bloquant , changeant à jamais la façon dont nous écrivons une lecture «fread» (E / S) ici en savoir plus).

En une phrase: la programmation non bloquante vise à mettre de côté les tâches chronophages, en spécifiant généralement ce qui doit être fait lorsque ces tâches sont terminées, et en permettant au processeur de traiter d'autres demandes alors que cela ne se produit pas.

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 boucle d'événement . Dans la plupart des langages, ce n’est pas une tâche facile: alors que le «rappel» est une fonctionnalité courante dans d’autres langages, une boucle d’événement ne l’est pas, et vous vous retrouverez souvent aux prises avec des bibliothèques externes (par exemple: Python, avec Tornade ). Mais en JavaScript, rappels ils sont intégrés au langage, tout comme les boucles d'événements, et presque tous les programmeurs qui ont touché JavaScript les connaissent (ou du moins les ont utilisés, même si Je ne comprends pas vraiment ce qu'est une boucle d'événements ). Tout à coup, chaque startup sur Terre pourrait réutiliser des développeurs (c'est-à-dire des ressources) à la fois du côté client et du côté serveur, problème d'offre d'emploi : «Nous cherchons Guru en Python».

Tout à coup, chaque startup sur Terre pourrait réutiliser des développeurs (c'est-à-dire des ressources) à la fois côté client et serveur, résolvant le problème de l'offre d'emploi: «Nous recherchons un Python Guru».

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? Durera? Je suis sûr que JavaScript aura une place importante dans le futur. Laissez-moi vous dire pourquoi:

• Programmation fonctionnelle

  JavaScript était le premier langage de programmation apporter le paradigme de programmation fonctionnelle pour les masses (bien sûr, Lisp est venu en premier, mais la plupart des programmeurs n'ont jamais créé d'applications pour les environnements de production utilisant Lisp). Lisp et soi, principales influences de Javascript , regorgent d'idées innovantes. Ces idées pourraient libérer nos esprits pour explorer de nouvelles techniques, modèles et paradigmes. Et ils utilisent tous JavaScript. Jeter un coup d'œil à monades , Numéros d'église , ou même (pour un exemple plus réel) les fonctions de collections faire Underscore.js , ce qui peut vous faire économiser des lignes et des lignes de code.

• Objets dynamiques et héritage de prototype

  La programmation orientée objet sans classe (et pas de hiérarchie de classes sans fin) permet un développement rapide (création d'objets, ajout de méthodes et utilisation) mais, plus important encore, réduit le temps de refactoring pendant les tâches de maintenance en permettant au programmeur de modifier les instances d'objet au lieu des classes. Cette rapidité et cette flexibilité ouvrent la voie à un développement rapide.

• JavaScript est Internet

  JavaScript était conçu pour Internet , est ici depuis le début, et ne partira pas . Toutes les tentatives pour le détruire ont échoué: voyez, par exemple, la chute de Applets Java , en remplaçant VBScript par TypeScript de Microsoft (qui compile pour JavaScript), et la mort de Flash entre les mains des marchés mobile et HTML5. Il est impossible de remplacer JavaScript sans casser des millions de pages Web, notre objectif devrait donc être de l'améliorer. Et il n'y a personne de meilleur pour le travail que le Comité technique 39 à l'ECMA.

  D'accord, des alternatives à JavaScript voient le jour tous les jours, comme CoffeeScript , Manuscrit et comme des millions de langages compilant pour JavaScript . Ces alternatives peuvent être utiles pour les stades de développement ( via des cartes sources ), mais ils échoueront à remplacer 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 (c'est-à-dire JavaScript). JavaScript n'est pas un langage d'assemblage: c'est un langage de programmation de haut niveau avec un code source que vous pouvez comprendre - vous devez donc 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 composants, un instrument et toutes sortes de choses que vous pouvez imaginer, en jouant avec l'arbre de syntaxe abstraite, en anglais) de votre programme comme si vous travaillaient avec une arborescence DOM.

JavaScript de bout en bout: Node.js et MongoDB

Voilà donc les raisons d'utiliser JavaScript. À présent, j'utiliserai 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 à peu près ce que dit le site Web Node.js. Mais Node.js est plus important que cela: c'est l'environnement d'exécution préféré pour toute application JavaScript ayant accès aux E / S. Même si vous ne prévoyez pas d'écrire votre application serveur principale avec Node.js, vous pouvez utiliser des outils basés 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 l'édition texte intégral du code.

  Donc, si vous envisagez d'écrire des applications JavaScript pour le serveur ou le client, vous devez vous familiariser avec Node.js, car vous devrez 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 utilisant JavaScript comme langage de requête, ce qui me permet de compléter la plateforme avec du JavaScript de bout en bout.

  MongoDB est un base de données sans schéma qui vous permet de conserver les objets de manière flexible et donc de vous adapter plus rapidement à l'évolution des besoins. De plus, il est hautement évolutif est basé sur la réduction de la carte , ce qui le rend adapté aux applications Big Data. MongoDB est si flexible qu'il peut être utilisé comme base de données sans schéma, comme stockage relationnel (même s'il ne prend pas en charge transactions ), ou même en tant que magasin clé-valeur pour la mise en cache des réponses.

Compositions de serveur avec Express.js

La mise en composants côté serveur n'est jamais facile. Mais avec Express.js (et Connect.js) est venu l’idée de «middleware». À mon avis, le middleware est le meilleur moyen de définir les composants sur le serveur. Si vous souhaitez comparer avec une norme connue, elle est très proche des tuyaux et des filtres.

L'idée de base est que votre composant fait partie d'un pipeline (un tuyau). Le pipeline traite une demande (entrante) et génère une réponse (sortante), mais son composant n'est pas responsable de la réponse entière. Au lieu de cela, il modifie simplement ce dont il a besoin, puis le délègue à la partie suivante du pipeline. Lorsque la dernière partie du pipeline termine le traitement, la réponse est renvoyée au client.

Nous appelons ces «morceaux du pipeline» (morceau de tuyau) un «middleware». Clairement, nous pouvons créer deux types de middleware:

• Intermédiaires : ceux qui traitent la demande et la réponse, mais qui ne sont pas entièrement responsables de la réponse elle-même, délèguent ensuite au middleware suivant.

• Finales : ceux qui ont l'entière responsabilité de la réponse finale. Ils traitent et modifient la demande et la réponse, mais n'ont pas besoin de déléguer au middleware suivant. Dans la pratique, il est recommandé de déléguer de toute façon au middleware suivant pour permettre une flexibilité architecturale (c'est-à-dire ajouter plus de middleware plus tard), même si ce middleware n'existe pas (donc dans ce cas, la réponse va directement au client).

  où commencer à apprendre le c++

Comme exemple concret, considérons un composant «utilisateur de gestion» sur le serveur. En termes de middleware, nous aurions à la fois des terminaux et des intermédiaires. Pour nos fins, nous aurions des fonctionnalités telles que la création d'un utilisateur et la liste des utilisateurs. Mais avant de pouvoir effectuer de telles actions, nous avons besoin de nos intermédiaires pour l'authentification (puisque nous ne voulons pas de requêtes non authentifiées entrant et créant des utilisateurs). Une fois que ces intermédiaires d'authentification ont été créés, nous pouvons simplement les brancher là où nous voulons transformer une fonctionnalité précédemment non authentifiée en une fonctionnalité authentifiée.

Applications d'une seule page

Le projet Init se concentre sur la création applications d'une seule page (SPA: application d'une seule page) . La plupart des développeurs Web ont été incités à essayer d'utiliser les SPA. J'en ai construit plusieurs (pour la plupart propriétaires), et je peux dire avec conviction qu'ils sont simplement l'avenir des applications Web. Avez-vous déjà comparé un SPA à une application Web traditionnelle via une connexion mobile? La différence de temps de réponse est de l'ordre de quelques dizaines de secondes.

Avez-vous déjà comparé un SPA à une application Web traditionnelle via une connexion mobile? La différence de temps de réponse est de l'ordre de quelques dizaines de secondes.

Les SPA sont l'avenir du Web - alors pourquoi voudriez-vous créer votre produit de manière traditionnelle? Un argument commun que j'entends est que les gens sont concernés par le référencement (optimisation des moteurs de recherche, optimisation des moteurs de recherche). Mais si vous traitez 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 quelques bons commentaires ici également.

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

On a beaucoup parlé de frameworks MVC * pour SPA . C'est un choix difficile, mais je dirais que les 3 premiers sont Backbone.js , Ember.js , est Angular.js .

Tous les trois sont bien considérés. Mais lequel 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 vous 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. Ember.js, d'autre part, est un cadre complet et professionnel pour la création de SPA. Il a plus d'attractions, mais aussi une courbe d'apprentissage plus longue.

Selon la taille de votre application, la décision peut être aussi simple que d'analyser le taux de fonctionnalités utilisées par rapport aux fonctionnalités disponibles, ce qui vous donnera une bonne idée.

Dans le cas d'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 composante. De cette manière, chaque composant est une application simple et l'application finale peut être aussi complexe que nous le souhaitons.

Le style est également un défi, mais nous pouvons à nouveau nous appuyer sur des cadres pour nous aider. 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 .

Bootstrap a été créé en utilisant la langue MOINS et c'est un logiciel libre, donc nous pouvons le modifier si nous en avons besoin. Il est livré avec de nombreux contrôles d'interface utilisateur qui sont bien documenté sur le site Web Bootstrap . PE encore, il y a un modèle de personnalisation qui vous permet de créer votre propre Bootstrap. Il est définitivement le bon gars 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 voir comment Init peut vous aider à les implémenter et à les maintenir. Notre solution est centrée sur plusieurs outils, eux-mêmes basés sur Node.js.

• Mocha.js est 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 exécuteur pour les exécuter automatiquement.

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

  calculateur de salaire temporaire à permanent

  Réponse longue: elle présente deux caractéristiques importantes (interfaces, reporters) et une absence significative: les assertions. Laissez-moi expliquer.

  • Interfaces : Peut-être que vous êtes familier avec les concepts TDD comme les suites et les tests unitaires, ou peut-être préférez-vous les idées de spécification de comportement de BDD avec «décrire» et «il 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 plusieurs rapporteurs. Par exemple, si vous devez alimenter un serveur d'intégration continue, vous pouvez trouver un rapporteur pour le faire.

  • 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, vous offrant encore plus de flexibilité. Il y a options abondantes , mais c'est là que Chai.js entre sur le terrain.

  Chai.js est une bibliothèque d'assertions flexible qui vous permet de choisir parmi trois styles d'assertions principaux:

  • Affirmer : Style classique de l'affirmation traditionnelle des ions TDD. Exemple:

    assert.equal(variavel, 'valor');

  • Attendre : Style d'assertion chaînable, le plus couramment utilisé dans BDD. Exemple:

    expect(variavel).to.equal ('valor');

  • Devrait : Également utilisé dans BDD, mais je préfère Expect car il devrait sembler répétitif avec la spécification comportementale «il (« devrait faire quelque chose… »)». Exemple:

    variavel.should.equal ('valor');

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

• Grunt.js :

  Grunt. minification (par exemple, avec UglifyJS ou Compilateur de fermeture ). Vous pouvez ajouter votre propre tâche automatisée à Grunt ou rechercher Registre Grunt ,, où il y a des centaines et des centaines de plugins disponibles (rappelez-vous: l'utilisation d'outils avec de grandes communautés derrière est payante). 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, nous devons d'abord évoquer l'idée d'espacement des noms de module (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 dès le début. De plus, cela vous aidera à adopter Injection de dépendance pour évitez que vos modules accèdent aux variables globales .)

• CouvertureJS :

  Couverture de code est une métrique pour évaluer vos tests. Comme son nom l'indique, cela vous indique dans quelle mesure votre code est couvert par la 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 ) dans votre code et générant une version instrumentée de votre code. Vous pouvez également générer des rapports pour alimenter votre serveur Intégration continue .

Utilisation des branches pour choisir des fonctionnalités

Lorsque j'ai lancé Init, j'avais besoin d'un moyen pour les utilisateurs d'activer et de désactiver diverses fonctionnalités dont ils pourraient avoir besoin dans leurs projets. J'ai décidé de prendre la décision radicale d'utiliser le système de branches de git pour implémenter cette fonctionnalité.

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

Pour l'instant, cette idée de fusion 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 le client.

Démarrez un projet avec Init et déployez Heroku aujourd'hui

Il n'y a jamais eu de moyen plus simple de démarrer un projet. Allez simplement à référentiel sur GitHub , vérifiez la branche avec les derniers commits (c'est le gestionnaire d'utilisateur, bien que cela puisse changer dans le futur) et ensuite:

1. Créez le répertoire de 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 une télécommande avec init

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

4. Téléchargez le fichier de processus Heroku

   git pull init usermanager

5. Avec Heroku Toolbelt installé, créez une application Heroku

   git pull init heroku-webprocess

6. Comme Ceinture porte-outils Heroku installé, créez une application Heroku

   heroku create

7. Poussez votre 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 grande idée. N'oubliez pas de consulter le référentiel Init pour les nouveaux correctifs et fonctionnalités - son développement est très actif et j'attends vos commentaires avec impatience.

Contenu traduit par Eduardo Kienetz, membre de Transbrunko , un marché des traductions techniques.