Η ιστορία

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

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

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

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

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

Οθόνη @media και (μέγιστο πλάτος:

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

'Εντάξει, ας φτιάξουμε τον ιστότοπο', λέτε.

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

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

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

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

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

Η πρόταση

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

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

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

• Συστατικά

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

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

  Για κάποια προβλήματα, κάπου υπάρχει μια καλύτερη λύση [Brainf * ck] (https://en.wikipedia.org/wiki/Brainfuck). ή σκατά μυαλά). Αλλά εφαρμόστε αυτήν τη λύση (σε Brainf * uck ) θα ήταν σχεδόν αδύνατο να γράψετε, πόσο μάλλον να το διαβάσετε. Θα σας κοστίσει χρόνο και τεράστια προσπάθεια. Σε γενικές γραμμές, θα πρέπει να χρησιμοποιείτε γλώσσες και πλατφόρμες που καθιστούν την ανάπτυξη εύκολη και όχι δύσκολη για εσάς (ή κάποιον που μπορεί να συνεργαστεί αργότερα).

• Κοινότητα

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

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

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

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

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

Είμαι προγραμματιστής ιστού από το 1998. Εκείνη την εποχή χρησιμοποιήσαμε το Perl για το μεγαλύτερο μέρος της ανάπτυξης του διακομιστή μας, και ακόμη και τότε είχαμε JavaScript από την πλευρά του πελάτη. Οι τεχνολογίες ιστού από την πλευρά του διακομιστή έχουν αλλάξει πάρα πολύ από τότε: περάσαμε διαδοχικά διαφορετικές τεχνολογίες και γλώσσες, όπως PHP, ASP, 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 είναι εξοικειωμένος με αυτούς (ή τουλάχιστον τους έχει χρησιμοποιήσει, ωστόσο δεν καταλαβαίνω πλήρως τι σημαίνει ένα γεγονός βρόχου ). Ξαφνικά, κάθε μία από τις εκκινήσεις στο Planet Earth θα μπορούσε να επαναχρησιμοποιήσει προγραμματιστές (π.χ. πόρους) τόσο από την πλευρά του πελάτη όσο και από την πλευρά του διακομιστή, επιλύοντας το πρόβλημα 'Python Guru Needed' .

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

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

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

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

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

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

• JavaScript στο Διαδίκτυο

  Το JavaScript ήταν σχεδιασμένο για το Διαδίκτυο , είναι εδώ από την αρχή και δεν πρόκειται να φύγει . Όλες οι προσπάθειες να την καταστρέψουν απέτυχαν, κοιτάξτε, για παράδειγμα, την πτώση του Εφαρμογές Java , η αντικατάσταση του VBScript για Microsoft, TypeScript (που μεταγλωττίστηκε σε 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 είναι κάτι παραπάνω: είναι ο προτιμώμενος χρόνος εκτέλεσης για οποιαδήποτε εφαρμογή με πρόσβαση I / O JavaScript. Ακόμα κι αν δεν σκοπεύετε να γράψετε την κύρια εφαρμογή διακομιστή σας με το 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 είναι ο καλύτερος τρόπος για τον καθορισμό στοιχείων στο διακομιστή. Εάν θέλετε να το συγκρίνετε με ένα γνωστό πρότυπο, πλησιάζει πολύ τα σωληνάρια και τα φίλτρα.

javascript λήψη ημερομηνίας χωρίς ώρα

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

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

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

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

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

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

Η εργασία Μέσα σε αυτό επικεντρωθείτε στη δημιουργία εφαρμογές μιας σελίδας (SPAs-Single-Page Applications) . Πολλοί προγραμματιστές ιστού έχουν πειρασθεί περισσότερες από μία φορές να προσπαθήσουν να δημιουργήσουν ΖΕΠ. Αναπτύχθηκα χρησιμοποιώντας πολλά (κυρίως ιδιόκτητα) και μπορώ να πω με βεβαιότητα ότι είναι απλώς το μέλλον των διαδικτυακών εφαρμογών. Έχετε συγκρίνει ποτέ ένα SPA με μια κανονική εφαρμογή ιστού σε μια σύνδεση μέσω κινητού; Η διαφορά στην απόκριση είναι δεκάδες δευτερόλεπτα.

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

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

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

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

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

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

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

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

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

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

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

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

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

• Mocha.js και Chai.js :

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

  σε τι χρησιμοποιείται το scala

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

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

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

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

  • Διεκδικώ : Κλασικό στυλ ισχυρισμού παλιού σχολείου. Π.χ .:

    assert.equal(variable, ”valor”);

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

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

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

    variable.should.equal(“valor”);

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

• Grunt.js :

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

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

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

• ΕξώφυλλοJS :

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

Χρησιμοποιώντας _Branches_ (_ramas_) για εναλλαγή λειτουργιών

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

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

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

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

Δεν υπήρξε ποτέ ευκολότερος τρόπος για να ξεκινήσετε ένα έργο. Παω σε Αποθήκη 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 create

7. Σπρώξτε το κύριο υποκατάστημα στο Heroku

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

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

δωρεάν χακαρισμένες πιστωτικές κάρτες με χρήματα 2017

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

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