Θυμάστε, οι παλιότεροι, την εποχή που όλα τα sites ήταν μία συλλογή στατικών σελίδων; Πριν την ύπαρξη των CGI scripts και του server side scripting με perl, php κ.λ.;
Για κάποιο λόγο, η ιδέα να επιστρέψω σε στατικές σελίδες, μου μοιάζει αρκετά ελκυστική. Όχι βέβαια με τις τεχνολογίες του ’90 -δύο δεκαετίες, σχεδόν, αργότερα, έχουμε πολύ καλύτερα εργαλεία. Και υπάρχει μία πληθώρα υπηρεσιών στις οποίες μπορεί να κάνει κανείς “outsource” οτιδήποτε θα απαιτούσε interactivity, όπως τα σχόλια (από IntenseDebate και Discus, μέχρι friendfeed).
Βασικά οι ιδέες που γυρνάνε στο μυαλό μου, χωρίς να έχω καταφέρει να τις τακτοποιήσω, είναι:
- compatibility και life expectancy
Το blog μου κοντεύει να κλείσει 6 χρόνια. Δεν βλέπω γιατί, δεν θα μπορούσε να κλείσει άλλα τόσα και πολύ περισσότερα. Θα είναι τόσο διαδεδομένη η PHP τότε; Η MySQL; Ο apache;
Λογικά ναι. Δηλαδή, βάζω και στοίχημα. Και να μην είναι, θα υπάρχουν άλλα αντίστοιχα, και σίγουρα τρόποι για migration. Αλλά… πού ξέρεις; Αυτό που έχω δει με τα χρόνια είναι ότι τελικά αυτό που σώζεται και μεταφέρεται πιο εύκολα είναι οι στατικές σελίδες. Έτσι π.χ. έχω το site μου από το 1997, ενώ άλλα που έφτιαξα πιο μετά έχουν χαθεί.
- distribution
Εδώ και μήνες ρίχνω κλεφτές ματιές, όποτε έχω λίγο χρόνο, στο Git, ένα version control system με μερικά ενδιαφέροντα χαρακτηριστικά, όπως την distributed αρχιτεκτονική που υποστηρίζει. [1]
Προσπαθώ να καταλάβω, να φανταστώ, πώς θα μπορούσε να είναι και να λειτουργεί ένα site που δεν “εξαρτάται” τόσο από το URL του. Που το περιεχόμενό του μπορείς να το κάνεις checkout ή clone, να το μεταφέρεις από δω και από κει, να υπάρχει σε πολλαπλές κόπιες, ίσως αλλαγμένο από άλλους χρήστες, σε διάφορα σημεία του internet. (Βέβαια, υπάρχουν προβλήματα, π.χ. πώς αντικαθιστάς notification mechanisms όπως οι ping servers+RSS ή ακόμη και τα post pings και trackbacks ή -ακόμη πιο σημαντικό- ποιο είναι το namespace που προσδιορίζει την ταυτότητα ενός άρθρου κ.λ.)
Για αυτό και έκανα διαθέσιμο το longtxt και μέσω git -για την ακρίβεια, το git είναι ο κυρίως μηχανισμός, αν και όχι δημοφιλής, και το www προστέθηκε στην συνέχεια.
Μερικά από τα παραπάνω δεν είναι πολύ πρωτότυπα. Μπορείτε να βρείτε παρόμοιες ιδέες πίσω από posts και projects όπως:
- Using Git to maintain your website [2]
- Git website howto
- How to Maintain Static Sites with Git & Jekyll
- Blogging Like a Hacker using Git and Jekyll
- introducing Hyde
- AYM CMS
- Loathsxome
- Flashbake: Free version-control for writers using git
- GitTorrent, The Movie
Σκέφτομαι ότι ίσως ακόμη και τα σχόλια να μπορούσαν να γίνονται ως contributions που θα γίνονται αργότερα merge στο main branch; Και πώς θα μπορούσε κάποιος να περιορίσει την πρόσβαση ή να κλείσει ένα site του οποίου τουλάχιστον το περιεχόμενο (ή και το layout) “επιπλέει” άναρχα σε πολλαπλές κόπιες σε servers και clients σε όλο τον κόσμο; Μήπως όμως, θα χρειαζόμασταν τότε πολύ περισσότερο μηχανισμούς ηλεκτρονικής υπογραφής;
Φαντάζομαι, μετά από όλα αυτά, τα εισαγωγικά στον τίτλο να εξηγούνται λίγο περισσότερο. :-)
Μπορεί όλα αυτά να μην βγάζουν τόσο νόημα. Αλλά ήθελα να τα γράψω για να τα έχω και εγώ ως reference την επόμενη φορά που θα ξαναπιάσω το θέμα… Δείτε τα ως τροφή για σκέψη…
–
[1] άλλα άρθρα σχετικά με το git
[2] αυτή την προσέγγιση πάνω-κάτω, από τεχνική άποψη, ακολούθησα για το longtxt.
Ένα πιο ευέλικτο setup για το deployment είναι το web-root clone να συγχρονίζεται σε κάποιο άλλο branch αντί για το master, πχ το live.
Το live τώρα θα είναι ένα branch-ετικέτα* θα μπορεί δηλαδή να αλλαξει ανά πάσα στιγμή σε οποιοδήποτε revision linear ή non linear. Ακριβώς για αυτό το λόγο το web-root δεν μπορεί να χρησιμοποιεί το git clone αλλά το git reset –hard origin/live.
*σκέψου το σαν tag που μπορεί όμως να αλλάζει.
Καλό, αλλά… Αν έχεις ένα σύστημα δημιουργίας στατικού site π.χ. από Markdown αρχεία, τότε τα HTML αρχεία δεν τα κάνεις track με Git (αφού κάθε φορά γίνονται generate από τα Markdown αρχεία). Απ’ ότι καταλαβαίνω δηλαδή, είναι περισσότερο χρήσιμο για όσους δημιουργούν άμεσα πάνω σε HTML αρχεία.
Υ.Γ. Καλό θα ήταν το comment preview να γίνεται μέσω ενός button, διότι το “live” παραείναι αργό/βαρύ για τον Firefox (μου). :(
@Aggelos: εξήγησε τί εννοείς “τα HTML αρχεία δεν τα κάνεις track με Git” pls -δεν κατάλαβα.
Ναι, μάλλον δεν ήμουν και πολύ σαφής.
Χρησιμοποιώ για τη σελίδα μου ένα custom σύστημα σε Ruby, παρόμοιο σε φιλοσοφία με το Jekyll, όπου η κάθε σελίδα HTML προέρχεται από το rendering ενός αντίστοιχου text file με Markdown syntax.
Οπότε π.χ. έχω το about.markdown το οποίο περιέχει Markdown, και το σύστημα το κάνει render σε about.html. Αυτό που κάνω track επομένως στο Git είναι τα source files (.markdown αρχεία) και όχι τα παραγόμενα HTML files τα οποία δεν αγγίζω ποτέ manually.
Σε αυτή την περίπτωση το “updating your site with Git” δεν είναι και πολύ χρήσιμο επομένως, διότι ενώ κάνω track τα .markdown αρχεία, θέλω να μεταφέρω (να κάνω push) τα HTML αρχεία.
Hope this makes sense. :)
@Aggelos: κάνω ουσιαστικά τα πρώτα μου βήματα στο git (έστω, τα δεύτερα) και δεν είμαι ο πιο ειδικός.
Μήπως όμως θα μπορούσες να αντιμετωπίζεις το HTML directory ως άλλο ένα ξεχωριστό git repo, το οποίο να κάνει αυτόματα commit τα HTML αρχεία μετά την δημιουργία τους; Θα σου έλυνε κάτι τέτοιο το πρόβλημα;
No worries, και εγώ τώρα μαθαίνω το Git. :)
Ναι, αυτό που λες θα μπορούσα να το κάνω, αλλά “δένει” το rendering με το upload το οποίο δεν είναι πάντα αυτό που θες (πχ αρκετές φορές θες να δεις αν η τελευταία σου αλλαγή δεν έσπασε κάτι πριν κάνεις upload). Θα μπορούσες βέβαια να μη το κάνεις αυτόματα παρά μόνο με ένα git push, αλλά τότε θα χρησιμοποιείς το Git σαν απλά ένα file uploader (και στην προκειμένη περίπτωση νομίζω ότι το rsync είναι αρκετά καλύτερο σε αυτή τη δουλειά).
Καλή ιδέα λοιπόν, αλλά νομίζω ότι έχει περισσότερο νόημα για όσους δουλεύουν απευθείας πάνω σε HTML αρχεία.
Μπορείς να χρησιμοποιήσεις ένα html branch μέσα στο ίδιο git repository που να περιέχει μόνο τα παραγόμενα html αρχεία. Αυτό μπορεί να ακούγεται κάπως περίεργο αλλά γίνεται (δείτε πχ το html branch του git repository).
Ένα howto εδώ: http://gitcasts.com/posts/empty-branches
Πολύ καλό! Αν και, πάλι, θα κάνω track κάτι που δε χρειάζεται να κάνω track, και θα χρησιμοποιώ το Git μόνο και μόνο για το “σπρώξιμο” των αρχείων. Δε ξέρω, μου φαίνεται λίγο άσχημη χρήση του Git έτσι. :/ Προσωπικά, πάντα, προτιμώ να έχω το rsync γι’ αυτή τη δουλειά.
Ωραίο website το gitcasts btw. :)
@Christos: thanks!
@Aggelos: αυτό που μου αρέσει εμένα είναι ότι η έννοια του git repo δίνει μία άλλη διάσταση στην έννοια του website. Η δυνατότητα να κάνει κάποιος (ή και εγώ!) clone το blog μου και να το κάνει sync με πολύ απλό τρόπο έχει κάτι που με ιντριγκάρει. Σκέψου π.χ. πόσο δύσκολο θα ήταν να “κόψουν” κάποια απολυταρχικά καθεστώτα ένα blog που 10άδες “φίλοι” του το κάνουν clone σε διάφορες διευθύνσεις. Αλλά και πόσο εύκολο ακόμη και για εσένα να το κάνεις backup.
Και βέβαια, έχεις και το merge. Collaborative blogs ή sites? Θα είχαν νέες δυνατότητες.
Το rsync καλό είναι, αλλά όχι τόσο fine tunned για “δημόσια” χρήση. IMHO πάντα.
Συμφωνώ με όσα λες, αλλά όπως είπες(?) είναι περισσότερο για public use παρά για κάποιο personal project.
@Aggelos: μπα; και ποιος σου είπε ότι σε ένα “personal project” δεν μπορούν να υπάρχουν collaborators; π.χ. μερικά server-side bots που να τραβάνε πληροφορίες για το activity μου από το flickr και το youtube και να τις προσθέτουν με μορφή posts στο remote git repo; Ε; :-)
Έστω, είναι περισσότερο χρήσιμο για collaborative projects, παρά για non-collaborative. Το αν κάτι έχει collaboration ή όχι δεν εξαρτάται από το αν το project είναι προσωπικό ή public. Οπότε έχεις δίκιο, άκυρη χρήση όρων. :-)