Η ιστορία

Λοιπόν, εσείς και ο σύντροφός σας είχατε αυτήν την υπέροχη ιδέα για μια επιχείρηση, σωστά;

Έχετε προσθέσει λειτουργικότητα στο σύστημα διανοητικά.

Συχνά ρωτάτε τους πιθανούς πελάτες τι σκέφτονται και όλοι το λατρεύουν.

ωριαία αμοιβή ελεύθερου επαγγελματία έναντι μισθού

Εντάξει, οπότε οι άνθρωποι το θέλουν. Υπάρχουν ακόμη και κάποια χρήματα που πρέπει να κερδίσετε. Και ο μόνος λόγος που δεν μπορούν να το έχουν είναι επειδή δεν το έχετε εφαρμόσει ακόμα.

Τότε τελικά κάτσεσαι μια μέρα και πες, 'Ας το κάνουμε αυτό!' Έτσι, προσπαθείτε να καταλάβετε πώς να εφαρμόσετε την επιχειρηματική λογική της εφαρμογής σας, τη δολοφονική δυνατότητα που θα προωθήσει το προϊόν: έχετε μια ιδέα για το πώς να το κάνετε και γνωρίζετε μπορώ κάνω.

'Ολοκληρώθηκε! Λειτουργεί! », Λες. Η απόδειξη της ιδέας σας είναι επιτυχής! Το μόνο που λείπει είναι η συσκευασία σε μια εφαρμογή Ιστού.

'Εντάξει, ας δημιουργήσουμε τον ιστότοπο', λέτε.

Και μετά συνειδητοποιείτε την αλήθεια: πρέπει να επιλέξετε μια γλώσσα προγραμματισμού. πρέπει να επιλέξετε μια (σύγχρονη) πλατφόρμα. πρέπει να επιλέξετε μερικά (σύγχρονα) πλαίσια. πρέπει να αγοράσετε (και να διαμορφώσετε) χώρο αποθήκευσης, βάσεις δεδομένων και παρόχους φιλοξενίας. χρειάζεστε μια διεπαφή διαχείρισης? χρειάζεστε ένα σύστημα άδειας? χρειάζεστε έναν διαχειριστή περιεχομένου.

Θέλετε να είναι ελαφρύ, θέλετε να είστε ευέλικτοι. Θέλετε να χρησιμοποιήσετε τεχνολογίες που θα σας βοηθήσουν να πετύχετε βραχυπρόθεσμα και μακροπρόθεσμα. Και δεν είναι πάντα εύκολο να επιλεγούν.

Έχετε δεκάδες και δεκάδες αρχιτεκτονικές αποφάσεις να λάβετε. Και θέλετε να λάβετε τις σωστές αποφάσεις: θέλετε να χρησιμοποιήσετε τεχνολογίες που επιτρέπουν ταχεία ανάπτυξη, συνεχή επανάληψη, μέγιστη απόδοση, ταχύτητα, αντοχή και πολλά άλλα. Θέλετε να είναι ελαφρύ, θέλετε να είστε ευέλικτοι. Θέλετε να χρησιμοποιήσετε τεχνολογίες που θα σας βοηθήσουν να πετύχετε βραχυπρόθεσμα και μακροπρόθεσμα. Και δεν είναι πάντα εύκολο να επιλεγούν.

«Είμαι συγκλονισμένος», λέτε, αισθάνομαι πραγματικά συγκλονισμένοι. Η ενέργειά σας δεν είναι πλέον η ίδια. Προσπαθείτε να ενώσετε τα κομμάτια, αλλά είναι πάρα πολύ δουλειά.

Η απόδειξη της ιδέας σας στεγνώνει αργά και πεθαίνει.

Η πρόταση

Αφού εγκατέλειψα τον εαυτό μου αμέτρητες ιδέες, αποφάσισα να δημιουργήσω μια λύση. Το ονομάζω έργο « Μέσα σε αυτό '(Ou, init.js).

Το κεντρικό μέρος της ιδέας είναι να έχουμε ένα ενιαίο έργο για να τα ξεκινά όλα, να επιτρέπει στον προγραμματιστή ή τον τεχνικό ιδρυτή να λαμβάνει όλες αυτές τις βασικές αποφάσεις ταυτόχρονα και να λαμβάνει πρότυπο κατάλληλη αρχική βάση βάσει αυτών των αποφάσεων. Ξέρω τι θα λένε οι επικριτές: «δεν μπορεί να εφαρμοστεί λύση σε όλα τα είδη προβλημάτων» (οι μισοί θα μισούν). Και μπορεί να έχουν δίκιο. Αλλά μπορούμε να κάνουμε το καλύτερο δυνατό για να δημιουργήσουμε μια κατάλληλη λύση και νομίζω ότι το Init πλησιάζει.

Για να επιτύχουμε καλύτερα αυτόν τον στόχο, πρέπει να έχουμε κατά νου κάποιες ιδέες. Κατά την ανάπτυξη του Init, σκέφτηκα:

• Συστατικά

  Το Componentization είναι βασικό χαρακτηριστικό οποιουδήποτε συστήματος καθώς επιτρέπει την επαναχρησιμοποίηση στοιχείων λογισμικού σε διαφορετικά έργα - που είναι ο κύριος στόχος του Init. Αλλά η εξισορρόπηση έρχεται επίσης με ένα υποπροϊόν, «εναλλαξιμότητα», το οποίο θα είναι ο καλύτερος σύμμαχός μας στην αντιμετώπιση πολλών διαφορετικών προβλημάτων με την «σχεδόν» την ίδια λύση.

• Ευκολία ανάπτυξης

  Για οποιοδήποτε πρόβλημα, έχει κάποιος μια καλύτερη λύση Brainf * ck . Όμως, η εφαρμογή αυτής της λύσης (στο Brainfuck) θα είναι πρακτικά αδύνατο να γραφτεί, πόσο μάλλον να διαβάζεται. Θα σας κοστίσει χρόνο και μια τεράστια προσπάθεια. Σε γενικές γραμμές, θα πρέπει να χρησιμοποιείτε γλώσσες και πλατφόρμες που διευκολύνουν την ανάπτυξη, όχι πιο δύσκολη για εσάς (ή όποιον μπορεί να εργαστεί αργότερα).

• Κοινότητα

  Όποια πλατφόρμα και αν επιλέξετε, βεβαιωθείτε ότι έχετε μια μεγάλη κοινότητα και μια που μπορεί να σας βοηθήσει με τα πιο κοινά και ασυνήθιστα προβλήματα. Θυμηθείτε: Το jQuery ενδέχεται να μην είναι η βιβλιοθήκη γρηγορότερα , καθαριστής , ή πιο κομψό - αλλά είναι νικητής μόνο λόγω του κοινότητα .

Λαμβάνοντας υπόψη αυτούς τους στόχους, θα σας δείξω πώς πήρα τις αποφάσεις μου κατά τη δημιουργία του Init.

Στον πυρήνα του, το Init εκμεταλλεύεται το «παράδειγμα» JavaScript πλήρους στοίβας «Παράδειγμα (μερικοί άνθρωποι αναφέρονται σε αυτό ή ένα υποσύνολο αυτού, όπως το Σημαίνει στοίβα ). Όταν εργάζεται με μια τέτοια στοίβα, το Init μπορεί να χρησιμοποιήσει μία μόνο γλώσσα δημιουργώντας ένα εξαιρετικά ευέλικτο περιβάλλον πλούσιο σε χαρακτηριστικά για την ανάπτυξη εφαρμογών ιστού. Με λίγα λόγια, σας επιτρέπει να χρησιμοποιείτε JavaScript όχι μόνο για την ανάπτυξη πελάτη και διακομιστή, αλλά και για τη δημιουργία, τη δοκιμή, τη δημιουργία προτύπων και πολλά άλλα.

Αλλά ας επιβραδύνουμε για μια στιγμή και αναρωτηθούμε: είναι πραγματικά καλή ιδέα να χρησιμοποιήσετε το JavaScript;

Γιατί επέλεξα JavaScript

Είμαι προγραμματιστής ιστού από το 1998. Πίσω εκεί χρησιμοποιήσαμε τον Perl για την περισσότερη ανάπτυξη από την πλευρά του διακομιστή, αλλά ακόμη και τότε είχαμε JavaScript από την πλευρά του πελάτη. Τεχνολογίες για διακομιστές Ιστού έχουν αλλάξει πάρα πολύ από τότε: έχουμε περάσει από κύμα σε κύκλο γλωσσών και τεχνολογιών όπως PHP, ASP, JSP, .NET, Ruby, Python, για να αναφέρουμε μερικές. Οι προγραμματιστές άρχισαν να συνειδητοποιούν ότι η χρήση δύο διαφορετικών γλωσσών για το περιβάλλον πελάτη και διακομιστή περιπλέκει τα πράγματα. Οι αρχικές προσπάθειες ενοποίησης με μία μόνο γλώσσα είχαν ως στόχο τη δημιουργία στοιχείων πελάτη στον διακομιστή και τη σύνταξη τους για JavaScript. Αυτό δεν λειτούργησε όπως αναμενόταν και τα περισσότερα έργα απέτυχαν (για παράδειγμα: αντικατάσταση ASP MVC Φόρμες ιστού ASP.NET , είναι GWT αναμφισβήτητα θα αντικατασταθεί στο εγγύς μέλλον από Πολυμερές ). Αλλά ήταν μια υπέροχη ιδέα: μία γλώσσα στον πελάτη και στον διακομιστή, που μας επέτρεπε να επαναχρησιμοποιήσουμε στοιχεία και πόρους (αυτή είναι η βασική λέξη: πόροι ).

Η απάντηση ήταν απλή: τοποθετήστε το JavaScript και όχι διακομιστή.

Το JavaScript στην πραγματικότητα [γεννήθηκε με την πλευρά του διακομιστή JavaScript] (http://www.infoworld.com/d/application-development/javascript-conquers-the-server-969) στον Netscape Enterprise Server, αλλά η γλώσσα δεν ήταν έτοιμη ΕΚΕΙΝΗ ΤΗΝ ΠΕΡΙΟΔΟ. Μετά από χρόνια δοκιμής και σφάλματος, το Node.js τελικά εμφανίστηκε, το οποίο όχι μόνο έβαλε τη JavaScript στον διακομιστή, αλλά προώθησε επίσης την ιδέα του προγραμματισμού χωρίς αποκλεισμό , αλλάζοντας για πάντα τον τρόπο με τον οποίο γράφουμε μια ανάγνωση 'Fread' (I / O) εδώ να μάθω περισσότερα).

Σε μια πρόταση: ο προγραμματισμός χωρίς αποκλεισμό στοχεύει στην απομάκρυνση χρονοβόρων εργασιών, καθορίζοντας γενικά τι πρέπει να γίνει όταν ολοκληρωθούν αυτές οι εργασίες και επιτρέποντας στον επεξεργαστή να χειριστεί άλλα αιτήματα, ενώ αυτό δεν συμβαίνει.

Αλλά αυτές οι ιδέες δεν ήταν νέες - γιατί γιατί έγιναν τόσο δημοφιλείς στο Node.js; Ο απλός προγραμματισμός χωρίς αποκλεισμούς μπορεί να επιτευχθεί με διάφορους τρόπους. Ίσως το πιο εύκολο είναι η χρήση επιστροφών κλήσης και a βρόχος συμβάντος . Στις περισσότερες γλώσσες, αυτό δεν είναι εύκολο καθήκον: ενώ το 'callback' είναι ένα κοινό χαρακτηριστικό σε άλλες γλώσσες, ο βρόχος συμβάντος δεν είναι, και συχνά θα βρεθείτε να παλεύετε με εξωτερικές βιβλιοθήκες (για παράδειγμα: Python, με Ανεμοστρόβιλος ). Αλλά σε JavaScript, επιστροφές είναι ενσωματωμένα στη γλώσσα, όπως και οι βρόχοι συμβάντων, και σχεδόν κάθε προγραμματιστής που έχει αγγίξει τη JavaScript είναι εξοικειωμένος με αυτούς (ή τουλάχιστον τις χρησιμοποίησε, ακόμη και αν δεν καταλαβαίνω πραγματικά τι είναι ένας βρόχος γεγονότος ). Ξαφνικά κάθε εκκίνηση στο Earth θα μπορούσε να επαναχρησιμοποιήσει προγραμματιστές (δηλαδή πόρους) τόσο από την πλευρά του πελάτη όσο και από τον διακομιστή, πρόβλημα προσφοράς εργασίας : «Αναζητούμε τον Γκουρού στη Python».

Ξαφνικά κάθε εκκίνηση στο Earth θα μπορούσε να επαναχρησιμοποιήσει προγραμματιστές (δηλαδή πόρους) τόσο από την πλευρά του πελάτη όσο και από τον διακομιστή, επιλύοντας το πρόβλημα της προσφοράς εργασίας: «Ψάχνουμε για έναν Python Guru».

Τώρα έχουμε ένα απίστευτα γρήγορη πλατφόρμα (χάρη στον προγραμματισμό χωρίς αποκλεισμό) με μια γλώσσα προγραμματισμού που είναι απίστευτα εύκολο στη χρήση (χάρη στο JavaScript). Αρκεί όμως αυτό; Θα κρατήσει? Είμαι βέβαιος ότι η JavaScript θα έχει σημαντική θέση στο μέλλον. Επιτρέψτε μου να σας πω γιατί:

• Λειτουργικός προγραμματισμός

  Η JavaScript ήταν η πρώτη γλώσσα προγραμματισμού για να φέρει το πρότυπο λειτουργικού προγραμματισμού για τις μάζες (φυσικά, η Lisp ήρθε πρώτη, αλλά οι περισσότεροι προγραμματιστές δεν δημιούργησαν ποτέ εφαρμογές για περιβάλλοντα παραγωγής χρησιμοποιώντας το Lisp). Lisp και Self, κύριες επιρροές του Javascript , είναι γεμάτα με καινοτόμες ιδέες. Αυτές οι ιδέες θα μπορούσαν να ελευθερώσουν το μυαλό μας για να εξερευνήσουν νέες τεχνικές, πρότυπα και παραδείγματα. Και όλοι παίρνουν JavaScript. Ρίξε μια ματιά στο μονάδες , Αριθμοί εκκλησίας ή ακόμα και (για ένα πιο πραγματικό παράδειγμα) τις συναρτήσεις συλλογών κάνω Underscore.js , που μπορεί να σας σώσει γραμμές και γραμμές κώδικα.

• Δυναμικά αντικείμενα και κληρονομικότητα πρωτοτύπου

  Ο Προγραμματισμός Χωρίς Αντικειμενικό Χωρίς Προγραμματισμό (και χωρίς ατελείωτη ιεραρχία τάξης) επιτρέπει την ταχεία ανάπτυξη (δημιουργία αντικειμένων, προσθήκη μεθόδων και χρήση τους), αλλά, το πιο σημαντικό, μειώνει το χρόνο αναδιαμόρφωσης κατά τη διάρκεια εργασιών συντήρησης επιτρέποντας στον προγραμματιστή να τροποποιεί τις παρουσίες αντικειμένων αντί των τάξεων. Αυτή η ταχύτητα και η ευελιξία ανοίγουν το δρόμο για ταχεία ανάπτυξη.

• Το JavaScript είναι το Διαδίκτυο

  Το JavaScript ήταν σχεδιασμένο για το Διαδίκτυο , βρισκόταν εδώ από την αρχή, και δεν θα φύγει . Όλες οι προσπάθειες να την καταστρέψουν απέτυχαν: δείτε, για παράδειγμα, την πτώση του Εφαρμογές Java , αντικαθιστώντας το VBScript με TypeScript της Microsoft (που μεταγλωττίζεται για JavaScript) και ο θάνατος του Flash στα χέρια των αγορών για κινητά και HTML5. Είναι αδύνατο να αντικαταστήσετε τη JavaScript χωρίς να σπάσετε εκατομμύρια ιστοσελίδες, οπότε οι στόχοι μας πρέπει να είναι να το βελτιώσουμε. Και δεν υπάρχει κανένας καλύτερος για τη δουλειά από το Τεχνική επιτροπή 39 στην ECMA.

  Εντάξει, γεννιούνται εναλλακτικές λύσεις για το JavaScript κάθε μέρα, όπως CoffeeScript , Τύπος γραφής και ως εκατομμύρια γλώσσες που συντάσσουν για JavaScript . Αυτές οι εναλλακτικές μπορούν να είναι χρήσιμες για τα στάδια ανάπτυξης ( μέσω χαρτών πηγής ), αλλά δεν θα αντικαταστήσουν μακροπρόθεσμα τη JavaScript για δύο λόγους: οι κοινότητές τους δεν θα είναι ποτέ μεγαλύτερες και οι καλύτερες δυνατότητές τους θα υιοθετηθούν από το σενάριο ECMA (π.χ. JavaScript). Το JavaScript δεν είναι γλώσσα συναρμολόγησης: είναι μια γλώσσα προγραμματισμού υψηλού επιπέδου με πηγαίο κώδικα που μπορείτε να καταλάβετε - οπότε πρέπει να το καταλάβετε.

Τώρα ευχαριστώ σε Πρόγραμμα Esprima , μπορείτε να δημιουργήσετε τα δικά σας εργαλεία για να παίξετε με τον πηγαίο κώδικα, να το τροποποιήσετε, να αλλάξετε το στυλ του, να προσθέσετε στοιχεία, όργανο και κάθε είδους πράγματα που μπορείτε να φανταστείτε, παίζοντας με το Abstract Syntax Tree, στα Αγγλικά) του προγράμματος σας σαν να δούλευα με ένα δέντρο DOM.

End-to-end JavaScript: Node.js και MongoDB

Έτσι, αυτοί είναι οι λόγοι για τη χρήση JavaScript. Τώρα, θα χρησιμοποιήσω το JavaScript ως λόγο για να χρησιμοποιήσω το Node.js και το MongoDB.

• Node.js

  ένας από τους πιο αποτελεσματικούς και ευκολότερους τρόπους για μια εταιρεία να αλλάξει την εικόνα της είναι:

  Το Node.js είναι μια πλατφόρμα για τη δημιουργία γρήγορων και επεκτάσιμων εφαρμογών δικτύου - αυτό είναι ακριβώς αυτό που λέει ο ιστότοπος Node.js. Αλλά το Node.js είναι πιο σημαντικό από αυτό: είναι το προτιμώμενο περιβάλλον εκτέλεσης για οποιαδήποτε εφαρμογή JavaScript με πρόσβαση στο I / O. Ακόμα κι αν δεν σκοπεύετε να γράψετε την κύρια εφαρμογή διακομιστή σας με το Node.js, μπορείτε να χρησιμοποιήσετε εργαλεία που έχουν δημιουργηθεί πάνω από το Node.js για να βελτιώσετε τη διαδικασία ανάπτυξης. Για παράδειγμα: Mocha.js για δοκιμή μονάδας, Grunt.js για αυτοματοποιημένες εργασίες κατασκευής ή ακόμα και Αγκύλες για επεξεργασία πλήρες κείμενο κωδικού.

  Επομένως, εάν πρόκειται να γράψετε εφαρμογές JavaScript για το διακομιστή ή τον πελάτη, θα πρέπει να εξοικειωθείτε με το Node.js, επειδή θα πρέπει να το χρησιμοποιείτε καθημερινά. Υπάρχουν μερικά ενδιαφέροντα εναλλακτικές λύσεις , αλλά κανένα από αυτά δεν φτάνει ακόμη και το 10% της κοινότητας Node.js.

• MongoDB

  MongoDB είναι μια βάση δεδομένων NoSQL με βάση έγγραφα που χρησιμοποιούν JavaScript ως γλώσσα ερωτήματος, επιτρέποντάς μου να ολοκληρώσω την πλατφόρμα με JavaScript από άκρο σε άκρο.

  Το MongoDB είναι ένα βάση δεδομένων χωρίς σχήμα που σας επιτρέπει να διατηρείτε αντικείμενα με ευέλικτο τρόπο και επομένως να προσαρμόζεστε πιο γρήγορα στις μεταβαλλόμενες απαιτήσεις. Επιπλέον, είναι εξαιρετικά κλιμακούμενος είναι με βάση τη μείωση χάρτη , που το καθιστά κατάλληλο για εφαρμογές μεγάλων δεδομένων. Το MongoDB είναι τόσο ευέλικτο που μπορεί να χρησιμοποιηθεί ως βάση δεδομένων χωρίς σχήμα, ως σχεσιακός χώρος αποθήκευσης (αν και δεν υποστηρίζει συναλλαγές ), ή ακόμη και ως κλειδί-τιμή για τις αποκρίσεις προσωρινής αποθήκευσης.

Διαμόρφωση διακομιστή με Express.js

Η συστατικοποίηση από την πλευρά του διακομιστή δεν είναι ποτέ εύκολη. Αλλά με Express.js (και Connect.js) ήρθε η ιδέα του «middleware». Κατά τη γνώμη μου, το middleware είναι ο καλύτερος τρόπος για τον καθορισμό στοιχείων στο διακομιστή. Αν θέλετε να συγκρίνετε με ένα γνωστό πρότυπο, είναι πολύ κοντά σε σωλήνες και φίλτρα.

Η βασική ιδέα είναι ότι το στοιχείο σας είναι μέρος ενός αγωγού (σωλήνας). Ο αγωγός επεξεργάζεται ένα αίτημα (εισερχόμενο) και δημιουργεί μια απόκριση (εξερχόμενη), αλλά το στοιχείο του δεν είναι υπεύθυνο για ολόκληρη την απόκριση. Αντ 'αυτού, απλώς τροποποιεί ό, τι χρειάζεται και μετά το μεταβιβάζει στο επόμενο μέρος του αγωγού. Όταν το τελευταίο μέρος του αγωγού ολοκληρωθεί η επεξεργασία, η απάντηση αποστέλλεται πίσω στον πελάτη.

Αναφερόμαστε σε αυτά τα «κομμάτια του αγωγού» (κομμάτι σωλήνα) ως «μεσαίο λογισμικό». Σαφώς, μπορούμε να δημιουργήσουμε δύο τύπους μεσαίου λογισμικού:

• Διαμεσολαβητές : εκείνοι που επεξεργάζονται το αίτημα και την απάντηση, αλλά δεν είναι πλήρως υπεύθυνοι για την ίδια την απόκριση, στη συνέχεια μεταβιβάζονται στο επόμενο μεσαίο λογισμικό.

• Τελικές εξετάσεις : εκείνοι με πλήρη ευθύνη για την τελική απάντηση. Επεξεργάζονται και τροποποιούν το αίτημα και την απάντηση, αλλά δεν χρειάζεται να μεταβιβαστούν στο επόμενο ενδιάμεσο λογισμικό. Στην πράξη, συνιστάται να μεταβείτε στο επόμενο ενδιάμεσο λογισμικό ούτως ή άλλως για να επιτρέψετε την αρχιτεκτονική ευελιξία (δηλαδή να προσθέσετε περισσότερο μεσαίο λογισμικό αργότερα), ακόμη και αν δεν υπάρχει αυτό το ενδιάμεσο λογισμικό (έτσι σε αυτήν την περίπτωση η απάντηση πηγαίνει κατευθείαν στον πελάτη).

Ως συγκεκριμένο παράδειγμα, σκεφτείτε ένα στοιχείο «διαχείριση χρήστη» στο διακομιστή. Όσον αφορά το μεσαίο λογισμικό, θα έχουμε τόσο τελικά σημεία όσο και μεσάζοντες. Για τους σκοπούς μας, θα έχουμε χαρακτηριστικά όπως η δημιουργία ενός χρήστη και η καταχώριση χρηστών. Αλλά προτού μπορέσουμε να πραγματοποιήσουμε τέτοιες ενέργειες, χρειαζόμαστε τους μεσάζοντες μας για έλεγχο ταυτότητας (καθώς δεν θέλουμε να εισάγονται και να δημιουργούνται χρήστες μη εξουσιοδοτημένα αιτήματα). Μόλις δημιουργηθούν αυτοί οι διαμεσολαβητές ελέγχου ταυτότητας, μπορούμε απλώς να τους συνδέσουμε όπου θέλουμε να κάνουμε μια προηγουμένως μη εξουσιοδοτημένη δυνατότητα σε μια επικυρωμένη δυνατότητα.

Εφαρμογές μίας σελίδας

Το έργο Init επικεντρώνεται στη δημιουργία εφαρμογές μίας σελίδας (SPA: Εφαρμογή μίας σελίδας) . Οι περισσότεροι προγραμματιστές ιστού έχουν δελεαστεί να χρησιμοποιούν SPA. Έφτιαξα πολλά (κυρίως ιδιόκτητα), και μπορώ να πω με πεποίθηση ότι είναι απλώς το μέλλον των διαδικτυακών εφαρμογών. Έχετε συγκρίνει ποτέ ένα SPA με μια παραδοσιακή εφαρμογή ιστού μέσω μιας σύνδεσης για κινητά; Η διαφορά στο χρόνο απόκρισης είναι της τάξης των δεκάδων δευτερολέπτων.

Έχετε συγκρίνει ποτέ ένα SPA με μια παραδοσιακή εφαρμογή ιστού μέσω μιας σύνδεσης για κινητά; Η διαφορά στο χρόνο απόκρισης είναι της τάξης των δεκάδων δευτερολέπτων.

Τα SPA είναι το μέλλον του διαδικτύου - γιατί λοιπόν να δημιουργήσετε το προϊόν σας με κληρονομικό τρόπο; Ένα κοινό επιχείρημα που ακούω είναι ότι οι άνθρωποι ασχολούνται με το SEO (βελτιστοποίηση μηχανών αναζήτησης, Βελτιστοποίηση μηχανών αναζήτησης). Αλλά εάν αντιμετωπίζετε τα πράγματα σωστά, αυτό δεν πρέπει να είναι πρόβλημα: το ίδιο το Google έχει πολύ καλό σεμινάριο για το πώς να το κάνετε και υπάρχουν μερικά καλά σχόλια εδώ επίσης.

MV * στην πλευρά του πελάτη με Backbone.js, Marionette.js και Twitter Bootstrap

Έχουν ειπωθεί πολλά πλαίσια MVC * για SPA's . Είναι μια δύσκολη επιλογή, αλλά θα έλεγα ότι οι πρώτες 3 είναι Backbone.js , Ember.js , είναι Angular.js .

Και τα τρία θεωρούνται καλά. Αλλά ποιο είναι το καλύτερο για εσάς;

Δυστυχώς, πρέπει να παραδεχτώ ότι έχω πολύ περιορισμένη εμπειρία με το Angular.js, οπότε θα σας αφήσω εκτός αυτής της συζήτησης. Τώρα, το Ember.js και το Backbone.js αντιπροσωπεύουν δύο διαφορετικούς τρόπους επίθεσης στο ίδιο πρόβλημα.

Backbone.js είναι μινιμαλιστικό, απλοϊκό και σας προσφέρει αρκετά για να δημιουργήσετε ένα απλό SPA. Το Ember.js, από την άλλη πλευρά, είναι ένα πλήρες και επαγγελματικό πλαίσιο για τη δημιουργία ΖΕΠ. Έχει περισσότερα αξιοθέατα, αλλά και μια καμπύλη μεγαλύτερης μάθησης.

Ανάλογα με το μέγεθος της εφαρμογής σας, η απόφαση μπορεί να είναι τόσο εύκολη όσο η ανάλυση του ποσοστού των λειτουργιών που χρησιμοποιούνται έναντι των διαθέσιμων λειτουργιών, κάτι που θα σας δώσει μια καλή ιδέα.

Στην περίπτωση του Init, ήθελα να καλύψω τα περισσότερα σενάρια, γι 'αυτό επέλεξα το Backbone.js για εύκολη δημιουργία SPA, με το Backbone.Marionette.View για συνιστώσα. Με αυτόν τον τρόπο, κάθε στοιχείο είναι μια απλή εφαρμογή και η τελική εφαρμογή μπορεί να είναι τόσο περίπλοκη όσο θέλουμε.

Το στυλ είναι επίσης μια πρόκληση, αλλά μπορούμε και πάλι να βασιστούμε σε πλαίσια για να μας βοηθήσουν. Για το CSS, δεν υπάρχει τίποτα καλύτερο από αυτό Bootstrap Twitter , το οποίο προσφέρει ένα πλήρες σύνολο έτοιμων προς χρήση στυλ και εύκολο να προσαρμοστεί .

Το Bootstrap δημιουργήθηκε χρησιμοποιώντας τη γλώσσα ΠΙΟ ΛΙΓΟ και είναι δωρεάν λογισμικό, οπότε μπορούμε να το τροποποιήσουμε αν χρειαστεί. Έρχεται με πολλά στοιχεία ελέγχου διεπαφής χρήστη που είναι καλά τεκμηριωμένο στον ιστότοπο Bootstrap . PE ακόμα, υπάρχει ένα μοντέλο προσαρμογής που σας επιτρέπει να δημιουργήσετε το δικό σας Bootstrap. Είναι σίγουρα ο σωστός τύπος για τη δουλειά.

Βέλτιστες πρακτικές: Grunt.js, Mocha.js, Chai.js, RequireJS και CoverJS

Τέλος, πρέπει να ορίσουμε μερικές από τις βέλτιστες πρακτικές μας και να δούμε πώς το Init μπορεί να σας βοηθήσει να τις εφαρμόσετε και να τις διατηρήσετε. Η λύση μας επικεντρώνεται σε πολλά εργαλεία, τα οποία με τη σειρά τους βασίζονται στο Node.js.

• Mocha.js είναι Chai.js :

  Αυτά τα εργαλεία σας επιτρέπουν να βελτιώσετε τη διαδικασία ανάπτυξής σας εφαρμόζοντας TDD ή BDD , παρέχοντας την υποδομή για να οργανώσετε τις δοκιμές μονάδας σας και έναν εκτελεστή για να τις εκτελείτε αυτόματα.

  Υπάρχει χιλιάδες πλαισίων για δοκιμή μονάδας για JavaScript. Γιατί λοιπόν να χρησιμοποιήσετε το Mocha.js; Σύντομη απάντηση: είναι ευέλικτη και πλήρης.

  Μεγάλη απάντηση: έχει δύο σημαντικά χαρακτηριστικά (διεπαφές, δημοσιογράφοι) και μια σημαντική απουσία: ισχυρισμούς. ΑΣΕ με να εξηγήσω.

  • Διεπαφές : Ίσως είστε εξοικειωμένοι με τις έννοιες TDD, όπως σουίτες και δοκιμές μονάδας, ή ίσως προτιμάτε τις ιδέες προδιαγραφής συμπεριφοράς του BDD με το 'περιγράψτε' και 'θα έπρεπε'. Το Mocha.js σας επιτρέπει να χρησιμοποιήσετε και τις δύο προσεγγίσεις.

  • Δημοσιογράφοι : Η εκτέλεση της δοκιμής σας θα δημιουργήσει αναφορές αποτελεσμάτων και μπορείτε να μορφοποιήσετε αυτά τα αποτελέσματα χρησιμοποιώντας πολλούς δημοσιογράφους. Για παράδειγμα, εάν θέλετε να τροφοδοτήσετε έναν διακομιστή συνεχούς ενοποίησης, μπορείτε να βρείτε έναν δημοσιογράφο για να το κάνει ακριβώς αυτό.

  • Έλλειψη βιβλιοθήκης ισχυρισμών : μακριά από το να είναι πρόβλημα, το Mocha.js σχεδιάστηκε για να σας επιτρέπει να χρησιμοποιείτε τη βιβλιοθήκη ισχυρισμών της επιλογής σας, δίνοντάς σας ακόμη μεγαλύτερη ευελιξία. Υπάρχει άφθονες επιλογές , αλλά εδώ μπαίνει το πεδίο στο Chai.js.

  Το Chai.js είναι μια ευέλικτη βιβλιοθήκη ισχυρισμών που σας επιτρέπει να επιλέξετε ανάμεσα σε τρία κύρια στυλ ισχυρισμού:

  • Διεκδικώ : Κλασικό στυλ παραδοσιακού ισχυρισμού ιόντων TDD. Παράδειγμα:

    assert.equal(variavel, 'valor');

  • Αναμένω : Στυλ αλυσίδας ισχυρισμού, που χρησιμοποιείται συνήθως στο BDD. Παράδειγμα:

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

  • Πρέπει : Χρησιμοποιήθηκε επίσης στο BDD, αλλά προτιμώ το Expect γιατί θα πρέπει να ακούγεται επαναλαμβανόμενο με τη συμπεριφορική προδιαγραφή «αυτό (« πρέπει να κάνει κάτι .. »)». Παράδειγμα:

    variavel.should.equal ('valor');

  Το Chai.js ταιριάζει απόλυτα με το Mocha.js. Χρησιμοποιώντας μόνο αυτές τις τρεις βιβλιοθήκες, μπορείτε να γράψετε τις δοκιμές σας σε TDD, BDD ή οποιοδήποτε στυλ μπορεί να φανταστεί κανείς.

• Grunt.js :

  Το Grunt.js σάς επιτρέπει να αυτοματοποιήσετε εργασίες δημιουργίας, οτιδήποτε από απλή αντιγραφή και επικόλληση και συνένωση αρχείων, έως προ-συλλογή προτύπων, σύνταξη γλωσσών στυλ (π.χ. SASS και LESS), δοκιμή μονάδας (με mocha.js), χνούδι και κώδικα ελαχιστοποίηση (για παράδειγμα, με UglifyJS ή Μεταγλωττιστής κλεισίματος ). Μπορείτε να προσθέσετε τη δική σας αυτοματοποιημένη εργασία στο Grunt ή να κάνετε αναζήτηση στο Μητρώο Grunt ,, όπου υπάρχουν εκατοντάδες και εκατοντάδες πρόσθετα (θυμηθείτε: η χρήση εργαλείων με μεγάλες κοινότητες πίσω αποδίδει). Ο Γκριντ μπορεί επίσης παρακολουθείτε τα αρχεία σας και ενεργοποιήστε ενέργειες όταν τροποποιούνται.

• ΑπαιτείταιJS :

  Το RequireJS μπορεί να ακούγεται σαν ένας άλλος τρόπος φόρτωσης των ενοτήτων AMD , αλλά μπορώ να σας διαβεβαιώσω ότι είναι πολύ περισσότερο από αυτό. Για να καταλάβουμε γιατί, πρέπει πρώτα να αναφέρουμε την ιδέα του χώρου ονομάτων των λειτουργικών μονάδων (για παράδειγμα, demo.views.hello), η οποία αποφεύγει τη μόλυνση του παγκόσμιου χώρου ονομάτων, τυλίγοντας κάθε ενότητα στον δικό της χώρο ονομάτων. Το πρόβλημα είναι ότι αυτές οι λειτουργικές μονάδες δεν μπορούν να επαναχρησιμοποιηθούν: εάν τροποποιήσετε το χώρο ονομάτων μιας «παρουσίας», τροποποιείτε το χώρο ονομάτων όλων των «παρουσιών». Σε αντίθεση με αυτό, το RequireJS σάς επιτρέπει να ορίζετε επαναχρησιμοποιήσιμες μονάδες από την αρχή. Επιπλέον, θα σας βοηθήσει να υιοθετήσετε Ενεση εξάρτησης Για αποφύγετε την πρόσβαση των ενοτήτων σας σε καθολικές μεταβλητές .)

• ΕξώφυλλοJS :

  Κάλυψη κώδικα είναι μια μέτρηση για την αξιολόγηση των δοκιμών σας. Όπως υποδηλώνει το όνομα, αυτό σας λέει πόσο καλύπτεται ο κώδικάς σας από την τρέχουσα σουίτα δοκιμών. Το CoverJS μετρά την κάλυψη κώδικα των δοκιμών σας με τη δημιουργία δηλώσεων (αντί για γραμμές κώδικα όπως JSCoverage ) στον κωδικό σας και δημιουργώντας μια οργανωμένη έκδοση του κωδικού σας. Μπορείτε επίσης να δημιουργήσετε αναφορές για να τροφοδοτήσετε τον διακομιστή σας Συνεχής ενσωμάτωση .

Χρήση των κλάδων για την επιλογή λειτουργιών

Όταν ξεκίνησα το Init, χρειαζόμουν έναν τρόπο για τους χρήστες να ενεργοποιήσουν και να απενεργοποιήσουν διάφορες δυνατότητες που μπορεί να θέλουν στα έργα τους. Αποφάσισα να κάνω το ριζοσπαστικό βήμα της χρήσης του συστήματος υποκαταστημάτων του git για την εφαρμογή αυτής της λειτουργικότητας.

Ουσιαστικά, κάθε κλάδος αντιπροσωπεύει μια δυνατότητα ή λειτουργικότητα που ένας χρήστης μπορεί να θέλει να συμπεριλάβει. Εάν ξεκινάτε ένα έργο από το μηδέν, ξεκινήστε από τον ελάχιστο κλάδο που χρειάζεστε και, στη συνέχεια, προσθέστε άλλες τεχνολογίες συγχωνεύοντας με τους επιθυμητούς κλάδους. Για παράδειγμα, ας υποθέσουμε ότι θέλετε να ξεκινήσετε το έργο σας με Backbone.js και Marionette.js. Λοιπόν, μπορείτε να ξεκινήσετε με τον κλάδο Backbone.js και να τον συγχωνεύσετε με τον κλάδο Marionette, συνεχίζοντας για κάθε λειτουργικότητα που θέλετε να προσθέσετε.

Προς το παρόν αυτή η ιδέα της συγχώνευσης για προσθήκη λειτουργικότητας μπορεί να χρησιμοποιηθεί μόνο για πρότυπα τεχνολογίας (για παράδειγμα: Backbone, Node, Express). Αλλά στο μέλλον θα μπορείτε να κάνετε εναλλαγή μεταξύ εφαρμογών back-end (για παράδειγμα, από MongoDB σε Postgres) και πελάτη.

Ξεκινήστε ένα έργο με το Init και αναπτύξτε το Heroku Today

Δεν υπήρξε ποτέ ευκολότερος τρόπος για να ξεκινήσετε ένα έργο. Απλώς πηγαίνετε στο αποθετήριο στο GitHub , ελέγξτε το υποκατάστημα με τις τελευταίες δεσμεύσεις (σε αυτό το σημείο είναι το usermanager, αν και μπορεί να αλλάξει στο μέλλον) και στη συνέχεια:

1. Δημιουργήστε τον κατάλογο για το έργο σας (ή χρησιμοποιήστε έναν υπάρχοντα).
2. Δημιουργήστε το αποθετήριο σας με το 'git init' (ή χρησιμοποιήστε ένα υπάρχον αποθετήριο).

3. Προσθέστε ένα τηλεχειριστήριο με init

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

4. Πραγματοποιήστε λήψη του αρχείου διεργασίας Heroku

   git pull init usermanager

5. Με το Heroku Toolbelt εγκατεστημένο, δημιουργήστε μια εφαρμογή Heroku

   git pull init heroku-webprocess

6. Σαν Ζώνη εργαλείων Heroku εγκατεστημένο, δημιουργήστε μια εφαρμογή Heroku

   heroku create

7. Σπρώξτε τον κύριο κλάδο σας στο Heroku

   τι κάνει ο CFO μιας εταιρείας

   git push heroku master
8. Επισκεφθείτε την εφαρμογή σας που εκτελείται στο Heroku!

Τώρα μπορείτε να ξεκινήσετε να αναπτύσσετε τη λειτουργία δολοφονίας σας με λίγες γραμμές κώδικα. Όχι μόνο αυτό, αλλά θα αναπτύσσετε με τις πιο σύγχρονες και αποδοτικές τεχνολογίες σε μια σουίτα ανάπτυξης που είναι τόσο αυτοματοποιημένη όσο θα μπορούσε.

Ελπίζω να μπορείτε να χρησιμοποιήσετε Μέσα σε αυτό για να ξεκινήσετε την επόμενη μεγάλη ιδέα σας. Θυμηθείτε να ελέγξετε το αποθετήριο Init για νέες διορθώσεις και δυνατότητες - η ανάπτυξή του είναι πολύ ενεργή και ανυπομονώ για τα σχόλιά σας.

Περιεχόμενο που μεταφράστηκε από τον Eduardo Kienetz, μέλος του Τρανμπράνκο , μια αγορά τεχνικών μεταφράσεων.