Η ιστορία

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

Προσθέσατε χαρακτηριστικά στο μυαλό σας.

Συχνά, ρωτάτε τους πιθανούς πελάτες για τις απόψεις τους, και όλοι το λατρεύουν.

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

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

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

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

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

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

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

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

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

Η πρόταση

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

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

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

• Συστατικά

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

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

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

• Κοινότητα

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

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

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

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

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

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

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

Στην πραγματικότητα το JavaScript γεννήθηκε με την πλευρά του διακομιστή JavaScript στον Netscape Enterprise Server, αλλά η γλώσσα απλά δεν ήταν έτοιμη εκείνη τη στιγμή. Μετά από χρόνια δοκιμής και σφάλματος, Node.js τελικά προέκυψε που όχι μόνο έβαλε τη JavaScript στον διακομιστή, αλλά επίσης προώθησε την ιδέα του μη αποκλεισμός προγραμματισμού , αλλάζοντας τον τρόπο με τον οποίο γράφουμε ένα 'fread' (I / O) για πάντα (διαβάστε εδώ για περισσότερα).

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

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

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

Τώρα έχουμε ένα απίστευτα γρήγορη πλατφόρμα (χάρη στον προγραμματισμό χωρίς αποκλεισμό) με μια γλώσσα προγραμματισμού που είναι εξαιρετικά εύκολη στη χρήση (χάρη στη 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 δεν είναι ως γλώσσα συναρμολόγησης: είναι μια γλώσσα προγραμματισμού υψηλού επιπέδου με τον πηγαίο κώδικα που μπορείτε να καταλάβετε - οπότε πρέπει να το καταλάβετε.

Τώρα χάρη στο Express έργο , μπορείτε να δημιουργήσετε τα δικά σας εργαλεία για να παίξετε με τον πηγαίο κώδικα, να το τροποποιήσετε, να αλλάξετε το στυλ του, προσθέτοντας σχόλια, όργανα και όλα τα είδη που μπορείτε να φανταστείτε παίζοντας με το 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 (και Σύνδεση.js ) ήρθε η ιδέα του «middleware». Κατά τη γνώμη μου, το middleware είναι ο καλύτερος τρόπος για τον καθορισμό στοιχείων στο διακομιστή. Αν θέλετε να το συγκρίνετε με ένα γνωστό μοτίβο, είναι πολύ κοντά σε σωλήνες και φίλτρα.

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

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

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

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

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

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

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

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

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

Client Side MV * με Backbone.js, Marionette.js και Twitter Bootstrap

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

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

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

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

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

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

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

Το Bootstrap δημιουργήθηκε χρησιμοποιώντας το ΠΙΟ ΛΙΓΟ γλώσσα και είναι ανοιχτού κώδικα, οπότε μπορούμε να την τροποποιήσουμε αν χρειαστεί. Έρχεται με έναν τόνο χειριστηρίων UX που είναι καλά τεκμηριωμένο στον ιστότοπο 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(variable, ”value”);

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

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

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

    variable.should.equal(“value”);

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

• Grunt.js :

  πώς χρησιμοποιείτε το bootstrap

  Το 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). Αλλά στο μέλλον, θα μπορείτε να κάνετε εναλλαγή μεταξύ εφαρμογών πελάτη (π.χ. από MongoDB σε Postgres) και εφαρμογών πελατών.

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

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

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

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

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

4. Αποκτήστε το υποκατάστημα που θέλετε

   git pull init usermanager

5. Αποκτήστε το αρχείο διεργασίας Heroku

   git pull init heroku-webprocess

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

   heroku create

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

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

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

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