Next Previous Contents

2. Το Μήνυμα Πρέπει να Περάσει.

Από το 1993 έχω την ευθύνη της τεχνικής πλευράς ενός μικρού Παροχέα ελεύθερης πρόσβασης, που ονομάζεται Chester County InterLink (CCIL) στο Δυτικό Τσέστερ της Πενσυλβάνια (είμαι συνιδρυτής του CCIL και κατασκεύασα το δικό μας μοναδικό πολυχρηστικό bulletin-board software --μπορείτε να το δείτε κάνοντας telnet στο locke.ccil.org. Σήμερα υποστηρίζει σχεδόν τρεις χιλιάδες χρήστες σε τριάντα γραμμές). Αυτή η δουλειά μου επέτρεπε ελεύθερη πρόσβαση στο δίκτυο επί 24ώρου βάσεως μέσω της 56Κ γραμμής του CCIL. in fact, it practically demanded it!

Επομένως, ήμουν μαθημένος στην χρήση του άμεσου ηλεκτρονικού ταχυδρομείου. Για κάποιους περίπλοκους λόγους ήταν δύσκολο να συνδέσω με SLIP τον υπολογιστή που έχω στο σπίτι μου (snark.thyrsus.com) και τον CCIL. Όταν, τελικά ,τα κατάφερα ανακάλυψα ότι πρέπει να συνδέομαι (telnet) περιοδικά στον "locke" για να παραλαμβάνω την αλληλογραφία μου. Αυτό που ήθελα για την αλληλογραφία μου ήταν να παραδίδεται στον snark έτσι ώστε να μπορώ να ειδοποιούμε όταν φτάνει και να μπορώ να την χειριστώ χρησιμοποιώντας όλα τα τοπικά εργαλεία μου.

Η απλή προώθηση μηνυμάτων με το sendmail δεν δούλευε, επειδή ο προσωπικός υπολογιστής μου δεν είναι συνεχώς στο δίκτυο και δεν έχει στατική διεύθυνση IP. Αυτο που ήθελα ήταν ένα πρόγραμμα που θα έπαιρνε τον έλεγχο πάνω από την SLIP σύνδεση μου και θα μετέφερε την αλληλογραφία μου να την παραλάβω τοπικά. Ήξερα ότι τέτοια προγράμματα υπήρχαν και ότι τα περισσότερα χρησιμοποιούσαν ένα απλό πρωτόκολλο που λέγεται ΡΟΡ(Post Office Protocol). Και ήμουν αρκετά σίγουρος ότι υπήρχε ένας ΡΟΡ3 σέρβερ που συμπεριλαμβάνεται στο BSD/OS λειτουργικό που βρισκόταν στον "locke".

Χρειαζόμουν έναν ΡΟΡ3 client. Έτσι, συνδέθηκα στο δίκτυο και βρήκα έναν. Στην πραγματικότητα Βρήκα τρεις τέσσερις. Χρησιμοποίησα pop-perl για λίγο, αλλά έλλειπε μια σημαντική δυνατότητα, Η δυνατότητα να μετατρέπονται οι διευθύνσεις των παραλαμβανόμενων μηνυμάτων ώστε η δυνατότητα απάντησης [reply] να δουλεύει σωστά.

Ιδού το πρόβλημα: υποθέστε ότι κάποιος που λέγεται "joe" στον "locke" μου έστειλε ένα μήνυμα [mail] Αν παραλάβω το μήνυμα στον snark και μετά επιχειρήσω να απαντήσω, το πρόγραμμα ηλεκτρονικού ταχυδρομείου θα προσπαθήσει να το στείλει σ' έναν "joe" που δεν υπάρχει στον snark. Η τακτική μετατροπής με το σερί των διευθύνσεων προς απάντηση [Reply addresses] στον "@ccil.org" γρήγορα αποδείχθηκε πολύ δύσκολη.

Ήταν κάτι που ο υπολογιστής έπρεπε οπωσδήποτε να κάνει για μένα. Κανένας, όμως, από τους υπάρχοντες ΡΟΡ clients δεν ήξερε πώς! Κι ερχόμαστε στο πρώτο μας μάθημα:

1) Κάθε καλή δουλειά στον χώρο του λογισμικό αρχίζει με την προσωπική φαγούρα του προγραμματιστή.

Ίσως αυτό θα έπρεπε να είναι ολοφάνερο (από παλιά έχει ειπωθεί, "Η ανάγκη είναι η μητέρα της εφεύρεσης") αλλά, πολύ συχνά, οι προγραμματιστές ξοδεύουν τις μέρες τους πασχίζοντας για ένα μεροκάματο φτιάχνοντας εφαρμογές που ούτε χρειάζονται ούτε τους ενδιαφέρουν. Όχι, όμως, και στον κόσμο του Linux--πράγμα που εξηγεί γιατί η μέση ποιότητα του λογισμικού για Linux είναι τόσο υψηλή.

Τι νομίζετε, λοιπόν; Ότι βούτηξα στην δίνη της κωδικοποίησης ενός ολοκαίνουργιου ΡΟΡ3 client για να ανταγωνιστεί τους υπάρχοντες; Με τίποτα στον κόσμο! Έριξα μια προσεκτική ματιά στα ΡΟΡ utilities που είχα στα χέρια μου, και αναρωτήθηκα "ποιό απ' όλα είναι πλησιέστερο σε αυτό που θέλω;".

2) Οι καλοί προγραμματιστές ξέρουν τι να γράψουν. Οι σπουδαίοι ξέρουν τι να ξαναγράψουν (και να ξαναχρησιμοποιήσουν).

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

Ο Linus Torvalds, για παράδειγμα, δεν έγραψε το Linux απ' την αρχή. Αντίθετα ,ξεκίνησε να ξαναχρησιμοποιεί κώδικα και ιδέες απ' το Minix, ένα μικρό Unix-οϊδές λειτουργικό για μηχανές 386. Τελικά, ο κώδικας Minix απομακρύνθηκε ή ξαναγράφτηκε εντελώς--όσο, όμως, ήταν εκεί λειτουργούσε σαν η σκάλα για το βρέφος που, τελικά, έγινε το Linux.

Στο ίδιο πνεύμα, άρχισα να ψάχνω για ένα ΡΟΡ utility που θα είχε καλό κώδικα, για να μου χρησιμεύσει σαν βάση προγραμματισμού.

Η παράδοση ελεύθερου κώδικα του Unix ήταν πάντα φιλική προς την επαναχρησιμοποίηση κώδικα (γι' αυτό τον λόγο το GNU project επέλεξε το Unix σαν βασικό λειτουργικό, παρά τις σοβαρές νομικές επιφυλάξεις για το ίδιο το λειτουργικό). Η κοινότητα του Linux ώθησε αυτή την παράδοση σχεδόν στα τεχνολογικά της όρια. Προσφέρει σε όλους terabytes ελεύθερου κώδικα. Έτσι, το να αφιερώνεις λίγο χρόνο για να βρεις την κατάλληλη εφαρμογή κάποιου άλλου είναι περισσότερο πιθανό να δώσει θετικά αποτελέσματα στον κόσμο του Linux, παρά οπουδήποτε αλλού.

Έτσι έγινε και στην δική μου περίπτωση. Μαζί με αυτά που βρήκα νωρίτερα, η δεύτερη έρευνά μου κατέληξε μ' ένα σύνολο εννέα υποψήφιων--το fetchpop, το PopTart, το get-mail, το gwpop, το pop-perl, το pimp, το popc, το popmail και το upop. Αυτό που εγκατέστησα πρώτο ήταν το 'fetchpop' του Seung-Hong Oh. Έβαλα το χαρακτηριστικό header rewrite σ' αυτό κι έκανα και κάποιες άλλες βελτιώσεις τις οποίες ο δημιουργός του συμπεριέλαβε στην έκδοση 1.9.

Λίγες βδομάδες αργότερα, όμως, σκόνταψα στον κώδικα του 'popclient' του Carl Harris και ανακάλυψα ότι είχα πρόβλημα. Αν και το 'fetchpop' είχε μερικές καλές ιδέες στον κώδικά του (όπως την λειτουργία σε κατάσταση daemon), μπορούσε να διαχειριστεί μόνο ΡΟΡ3 και ήταν ερασιτεχνικά κωδικοποιημένο (ο Seung-Hong Oh ήταν ένας έξυπνος αλλά άπειρος προγραμματιστής και τα δύο αυτά χαρακτηριστικά του εκδηλώθηκαν στο πρόγραμμα αυτό). Ο κώδικας του Carl ήταν καλύτερος, αληθινά επαγγελματικός και σταθερός, αλλά από το πρόγραμμά του έλειπαν πολλά σημαντικά και μάλλον δύσκολα στην υλοποίησή τους χαρακτηριστικά που ήδη είχε το fetchpop (συμπεριλαμβανομένων κι αυτών που κωδικοποίησα εγώ).

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

Ένα πρακτικό κίνητρο για να τα παρατήσω ήταν η παρουσία υποστήριξης πολλαπλών πρωτοκόλλων. Από τα πρωτόκολλα που χρησιμοποιούν οι διαμετακομιστές ταχυδρομείου το ΡΟΡ3 ήταν το πιο κοινό, αλλά όχι το μοναδικό. Το fetchpop και οι άλλοι ανταγωνιστές του δεν υποστήριζαν ΡΟΡ2, RPOP ή APOP και σκεφτόμουν, ήδη, να προσθέσω IMAP (Ιnternet Message Access Protocol, το πιο καινούριο και πιο ισχυρό πρωτόκολλο ταχυδρομείου) IMAP, μόνο και μόνο για την ευχαρίστηση μου.

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

3)"Σχεδιάζεις να απορρίψεις κάποιο πρόγραμμα; Θα το κάνεις, ούτως ή άλλως". (Fred Books, "The Mythical Man-Month", chapter 11)

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

Λοιπόν (είπα στον εαυτό μου) οι αλλαγές που έκανα στο fetchpop ήταν η πρώτη προσπάθεια. Έτσι, τα παράτησα.

Μετά την παράδοση του πρώτου συνόλου διορθωτικών πακέτων κώδικα για το popclient [popclient paches] που έστειλα στον Carl Harris στις 25 Ιουνίου 1996, ανακάλυψα ότι είxε χάσει το ενδιαφέρον του για το popclient λίγο καιρό πριν. Ο κώδικας ήταν λίγο σκόρπιος, με μικρά bugs εδώ κι εκεί. Είχα πολλές αλλαγές να κάνω και κατέληξα γρήγορα στο ότι το πιο λογικό πράγμα που έπρεπε να κάνω ήταν να αναλάβω το πρόγραμμα.

Σχεδόν χωρίς να το προσέξω, το project κλιμακώθηκε. Δεν θα καταπιανόμουν άλλο με ασήμαντα διορθωτικά πακέτα [patches] για τους υπάρχοντες ΡΟΡ clients. Ξεκίνησα να δουλεύω πάνω σ' έναν απ' αυτούς και οι ιδέες στριμώχνονταν μέσα στο μυαλό μου και ήξερα ότι, πιθανόν, να οδηγήσουν σε μεγάλες αλλαγές.

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

4) Αν η συμπεριφορά σου είναι σωστή, θα συναντήσεις ενδιαφέροντα προβλήματα.

Η συμπεριφορά του Carl Harris, όμως, ήταν ακόμη πιο σημαντική. Αντιλήφθηκε ότι

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

Χωρίς ποτέ να χρειαστεί να το συζητήσουμε, ο Carl κι εγώ ξέραμε ότι είχαμε τον κοινό στόχο να δώσουμε τις καλύτερες λύσεις. Το μόνο ερώτημα και των δύο, ήταν αν ήμουν κατάλληλος γι' αυτή την δουλειά. Μια φορά που του έδειξα ότι ήμουν, αντέδρασε γενναιόδωρα. Ήλπιζα να αντιδράσω κι εγώ έτσι, όταν θα ερχόταν η σειρά μου._


Next Previous Contents