Μια μέρα πριν από 3 χρόνια στην ομάδα The Codest ετοιμάσαμε ένα σπουδαίο παιχνίδι Cody για προγραμματιστές Ruby. Στο σημερινό άρθρο θα ήθελα να περιγράψω πώς ήταν η δουλειά πάνω σε αυτό το έργο και κυρίως να σας δείξω τον κώδικα του έργου, ο οποίος από εδώ και στο εξής είναι δημόσια διαθέσιμος στο github μας.
Σχεδιασμός παιχνιδιού
Όταν σχεδιάζαμε το παιχνίδι, ο κύριος στόχος μας ήταν να προετοιμάσουμε μια διασκεδαστική ψυχαγωγία για τους προγραμματιστές, καθώς και να κάνουμε κάτι ενδιαφέρον ως μέρος της εργασίας στην εταιρεία μας. Μέχρι στιγμής, δεν είχαμε καμία αρμοδιότητα στη δημιουργία παιχνιδιών, γι' αυτό και μας έπληξε μια σημαντική πρόκληση. Κατ' αρχάς, επικεντρωθήκαμε στο τι πραγματικά ήταν αυτό το παιχνίδι. Αφού καταλήξαμε στο αρχικό σχέδιο, αναλάβαμε δράση.
Στο πλαίσιο των εργασιών για το παιχνίδι, αποφασίσαμε να διοργανώσουμε ένα hackathon και να χωριστούμε σε ομάδες που θα εκτελούσαν συγκεκριμένες εργασίες. Με έναν τέτοιο 8ωρο καταμερισμό εργασίας, καταφέραμε να υλοποιήσουμε την εμφάνιση των αντιπάλων στο παιχνίδι, ολόκληρη τη διάταξη και τη βάση τόσο των εργασιών όσο και των APIs ολόκληρου του συστήματος. Κατά τη διάρκεια του επόμενου σταδίου, συγκεντρωθήκαμε για 4ωρες συναντήσεις μια φορά το μήνα, χάρη στις οποίες καταφέραμε να ολοκληρώσουμε το παιχνίδι σε 3 συναντήσεις.
Εφαρμογή
Καθώς ειδικευόμαστε στο RubyOnRails, επιλέξαμε την τεχνολογία αυτή ως την κορυφαία. Ωστόσο, το παιχνίδι δεν επρόκειτο να είναι κειμενικό και ως εκ τούτου η προσέγγισή του αντανακλάται στην εφαρμογή τύπου SPA. Στο πλαίσιο της εργασίας, δουλέψαμε πάνω σε μια γνωστή αγωγό περιουσιακών στοιχείων από rails (το 2016 δεν υπήρχε κάτι καλύτερο κατ' αρχήν) και ολόκληρο το javascript με βάση την ιδιόκτητη κωδικός με τη βοήθεια του TypeScript. Στην εφαρμογή, υπήρχε ένας τυπικός καταμερισμός αρμοδιοτήτων: Rails ως στοιχείο ενεργητικού και πηγή API, javascript και σχετικό ως αλληλεπίδραση με τον χρήστη. Εδώ, ωστόσο, λειτούργησε ως υβρίδιο και ορισμένες προβολές απλώς αποδόθηκαν από τα rails, ενώ κάποιες άλλες - από το JS.
Δακτυλογραφημένο κείμενο
Ήταν το πρώτο μας πείραμα σε αυτόν τον τομέα. Ήταν εποχές που οι άνθρωποι πίστευαν στην επιτυχία του CoffeScript. Η χρήση του TypeScript απαιτούσε την εισαγωγή ενός typescript-rails gem. Δυστυχώς, αυτό δεν ήταν το τελικό, καθώς η typescript, που είναι στατικά τυποποιημένη γλώσσα, το απαιτούσε επίσης από τις βιβλιοθήκες που είναι προσαρτημένες εξ ορισμού στο rails.
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/jquery.d.ts (ειδικά όταν χρησιμοποιείται το ενσωματωμένο σύστημα διαχείρισης περιουσιακών στοιχείων με ράγες).
Το Cody ως παιχνίδι απαιτούσε πολλή δυναμική από την πλευρά του προγράμματος περιήγησης, καθώς και την τροποποίηση του δέντρου του DOM. Η χρήση του TypeScript αντί της vanilla javascript ήταν ένα τεράστιο άλμα στην ποιότητα του κώδικα, η ίδια η παρουσία των κλάσεων και της ενθυλάκωσης ήταν πολύ δελεαστική για εμάς.
API και SPA
Το 2019, η διαχείριση των εφαρμογών SPA γίνεται με τη χρήση των υπέροχων React ή Vue βιβλιοθήκες. Ωστόσο, το 2015, το κάναμε με διαφορετικό τρόπο. Η προαναφερθείσα typescript ήταν χρήσιμη στην υλοποίηση του παιχνιδιού, ενώ η jQuery ανακάλεσε όλη τη δουλειά που σχετίζεται με την αίτηση xml http. Τώρα μπορούμε να χρησιμοποιήσουμε το fetch, ενώ εκείνες τις ημέρες το `$ .ajax` ήταν το μόνο που χρειαζόταν για τη δουλειά. Ρίξτε μια ματιά στο client api μας!
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/services/api_client.js.ts
Αν ήταν api, τότε έπρεπε να λύσετε με κάποιο τρόπο το πρόβλημα του ελέγχου ταυτότητας, έτσι δεν είναι; Λοιπόν, αυτό είναι σωστό. Αλλά σε αυτή την περίπτωση, πήγαμε μετά (είναι δυνατόν να γράψω εδώ - χρησιμοποιήσαμε την μπάντα;!) την μπάντα και στη σύνοδο των rails δημιουργήσαμε το cookie_key και στη συνέχεια το αποθηκεύσαμε στη βάση δεδομένων. Ως εκ τούτου γνωρίζαμε ότι όλα ήταν κάτι παραπάνω από καλά.
https://github.com/codesthq/cody_the_game/search?q=cookie_key&unscoped_q=cookie_key
Η κατάσταση του παιχνιδιού ήταν αποθηκευμένη στη βάση δεδομένων και οι πληροφορίες σχετικά με το πόσοι χρήστες είχαν πόντους προέρχονταν από τη βάση δεδομένων (είναι η ίδια βάση δεδομένων; Μπορούμε απλά να την αλλάξουμε με μια αντωνυμία;). Το ACID είναι πάντα χρήσιμο όταν δεν υπάρχει προσωρινή αποθήκευση δεδομένων από την πλευρά του συστήματος;)
Στην περίπτωση του σπα, είναι το καλύτερο χωρίς επαναφόρτωση της σελίδας. Το λύσαμε κλασικά και η άγκυρα html ήταν η καλύτερη λύση χωρίς την επέκταση περιττών εξαρτήσεων. Γιατί ποιος θα χρησιμοποιούσε turbolinks;
SnapSVG
Αν σχεδιάσουμε ένα παιχνίδι, πρέπει να κυκλοφορήσει μόνο με εξαιρετικά γραφικά και κινούμενα σχέδια. Τότε ξοδέψαμε πολλές ώρες αναρωτώμενοι πώς να ικανοποιήσουμε αυτές τις απαιτήσεις στην εφαρμογή μας. Από τη μία πλευρά, ο καμβάς μπορεί να κάνει θαύματα, από την άλλη, σε μια καθαρή html είναι πολύ πιο εύκολο να προλάβουμε και όλοι το γνωρίζουν. Μετά από μια επίπονη αναζήτηση της καλύτερης λύσης, καταλάβαμε ότι ο συνδυασμός αυτών των δύο λύσεων είναι το svg. Σας επιτρέπει να παρουσιάζετε εύκολα γραφικά σε διανυσματική μορφή, είναι γραμμένο σε γλώσσα σήμανσης και, το σημαντικότερο, μπορεί να τροποποιηθεί εν κινήσει. Είναι σημαντικό ότι υπάρχει μια βιβλιοθήκη για αρχεία svg που λειτουργεί παρόμοια με την jQuery και επιτρέπει λειτουργίες στην εικόνα με ενιαίο τρόπο. Αυτή είναι η: http://snapsvg.io, έχουμε πολύ ωραίες αναμνήσεις από τη συγκεκριμένη χρήση της λύσης.
Ένα παράδειγμα για το πώς χρησιμοποιήσαμε το snap.svg μπορείτε να βρείτε παρακάτω:
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/intro.js.ts
Το ίδιο το αρχείο haml με τον σκελετό των γραφικών:
https://github.com/codesthq/cody_the_game/blob/master/app/views/game/show.html.haml
Όπως μπορείτε να δείτε, είναι σχεδόν σαν ένα κανονικό δέντρο DOM και μια κανονική εφαρμογή rails!
TrustedSandbox
Λοιπόν, τελικά είχαμε API, Graphics, SPA. Τι γίνεται όμως με την υλοποίηση των λύσεων που στέλνουν οι χρήστες;
Το πρώτο πράγμα που μου έρχεται στο μυαλό είναι η μέθοδος eval, αλλά δεν είμαστε τρελοί;) Πίσω στο 2016, το docker βρισκόταν σε άνοδο, οπότε έμοιαζε με φυσική επιλογή. Τα ίδια τα κοντέινερ δεν εξασφάλιζαν πλήρη απομόνωση και προστασία, γι' αυτό και χρησιμοποιήσαμε μια έτοιμη λύση στο Ruby που ονομάζεται https://github.com/vaharoni/trusted-sandbox. Επέτρεπε την καλύτερη προστασία του κώδικα πριν από την έξοδο από το sandbox και με τυποποιημένο τρόπο τη διαμόρφωση των απαιτήσεων του λειτουργικού συστήματος. Ήταν πολύ σημαντικό να περιοριστεί σωστά ο χρόνος εκτέλεσης του κώδικα, η μνήμη που απαιτείται για τη λειτουργία και οι κύκλοι της CPU. Η διαμόρφωσή μας είναι διαθέσιμη παρακάτω
https://github.com/codesthq/cody_the_game/blob/master/config/trusted_sandbox.yml.example
Φυσικά, το ίδιο αξιόπιστο sandbox δεν εγγυάται τίποτα, γι' αυτό και δημιουργήσαμε έναν ειδικό ιστότοπο για την εκτέλεση του κώδικα.
https://github.com/codesthq/cody_the_game/blob/master/app/services/task_runner/base_task.rb
Κάθε μία από τις εργασίες είχε τη δική της περίπτωση δοκιμής, η οποία μας επέτρεψε να επαληθεύσουμε την ορθότητα της υλοποιημένης λύσης. Αυτό έγινε με την εισαγωγή του κώδικα του χρήστη στην περίπτωση δοκιμής, έτσι ώστε όλα να εκτελούνται απομονωμένα.
https://github.com/codesthq/cody_the_game/blob/master/app/challenges/challenge/case.rb
Φυσικά, αυτή η ενέργεια κόστισε αρκετό χρόνο και, ενώ συλλέγαμε τις απαντήσεις, δεν είχαμε την πολυτέλεια να τρέξουμε το sandbox, οπότε αποθηκεύσαμε μόνο τον κώδικα στη βάση δεδομένων, δημιουργώντας μια υποβολή και στη συνέχεια, χρησιμοποιώντας long pooling, ζητήσαμε από το τελικό σημείο να λάβει την κατάσταση του κώδικα. Αυτό μας επέτρεψε να ανακουφίσουμε τον διακομιστή εφαρμογών και να επαληθεύσουμε κατάλληλα τα δεδομένα. Φυσικά, έπρεπε επίσης να προστατευτούμε από το "κρασάρισμα του σεναρίου" και γι' αυτό περιορίσαμε τον αριθμό των ερωτημάτων του διακομιστή χρησιμοποιώντας τη μεταβλητή ttl, η οποία φαίνεται παρακάτω.
https://github.com/codesthq/cody_the_game/blob/master/app/assets/javascripts/level_controller.js.ts#L92
Περίληψη του διαγωνισμού
Μέχρι τον Σεπτέμβριο του 2011, τα στατιστικά στοιχεία του παιχνιδιού είχαν ως εξής:
- αριθμό συνεδριών: 1945 - αποστέλλονται εργασίες: 4476 - έστειλε σωστές απαντήσεις: 1624 - τελείωσε το παιχνίδι: 31
Όπως μπορείτε να δείτε, οι μεγαλύτερες σκάλες ξεκίνησαν στην εργασία # 2 επειδή δεν ήταν πλέον ένα συνηθισμένο παράδειγμα hello world.
Διαβάστε επίσης:
Μια γρήγορη κατάδυση στη Ruby 2.6. Τι είναι καινούργιο;
Η συγγραφή τεκμηρίωσης έγινε εύκολη χάρη στο VuePress
Vue.js βασικό σεμινάριο. Πώς να ξεκινήσετε με αυτό το πλαίσιο;