Archive for the programming Category

Μπίζνες

Posted in programming on 30 Δεκεμβρίου 2008 by mathpoet

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

Έχουμε όμως ένα μεγάλο πλεονέκτημα σε αντίθεση με άλλους μαστόρους. Μπορούμε να παρέχουμε άμεσα το προϊόν μας σε οποιονδήποτε στον κόσμο. Δεν είναι απαραίτητο να υπάρχουν εταιρεία, πωλητές, διανομείς κλπ. Αρκεί ένα ανέβασμα στο διαδίκτυο. Αυτό φυσικά σημαίνει και τεράστιο ανταγωνισμό, αλλά εκεί φαίνεται ο καλός ο μάστορας. Τι πιο ωραίο παράδειγμα για να στηρίξω την άποψή μου, από την εφαρμογή iFart (εγώΠέρδομαι ελληνιστί). Διαβάζω σε αυτό το άρθρο ότι σε 2 ημέρες, οι δημιουργοί του έβγαλαν πάνω από 40.000$ και είναι η Νο 1 επί πληρωμή εφαρμογή στον ιστότοπο της Apple. Υπάρχει ακόμα και εκτενής κριτική στην οποία το βαθμολόγησαν με 3,5/5 και προτείνουν κάποιες βελτιώσεις.

Οπότε συνάδελφοι, σταματήστε να σπαταλάτε τον χρόνο σας στο projecteuler, call of duty,… και υλοποιήστε μια ιδέα. Οι δυνατότητες είναι άπειρες. Ακόμα και με πορδές βάφονται τα αβγά. Επίσης αν δεν θέλετε να πουλήσετε, μπορείτε να ανεβάσετε κάτι ως ελεύθερο ή έστω δωρεάν λογισμικό. Είναι πολύ ωραίο το συναίσθημα όταν μαθαίνεις πως βοήθησες ανθρώπους σε διάφορα μέρη του πλανήτη. Όποιος έχει καμιά ιδέα και δεν θέλει/μπορεί ας κάνει κανένα σχόλιο μήπως ενεργοποιηθεί και ο υποφαινόμενος.

ΥΓ: Στα σχόλια του άρθρου κάποιος λέει ότι του θύμισε την ταινία Idiocracy. Βρίσκω τον συνειρμό πολύ πετυχημένο και με την ευκαιρία συστήνω την ταινία ανεπιφύλακτα.

Sudoku for nerds

Posted in programming on 23 Δεκεμβρίου 2008 by mathpoet

Από αυτό το πολύ ενδιαφέρον άρθρο, ανακάλυψα το projecteuler.net. Έχει μια λίστα από ωραίες προγραμματιστικές σπαζοκεφαλιές, η οποία ανανεώνεται συνεχώς. Κάποια προβλήματα απαιτούν ένα σχετικό μαθηματικό υπόβαθρο, αλλά δεν είναι όλα έτσι.  Τα πιο διασκεδαστικά, τουλάχιστον για εμάς τους μη-μαθηματικούς,  λύνονται βρίσκοντας έναν αποδοτικό αλγόριθμο γιατί η εξαντλητική αναζήτηση (brute force) είναι ασύμφορη. Χαρακτηριστικό παράδειγμα είναι το πρόβλημα 119:

The number 512 is interesting because it is equal to the sum of its digits raised to some power: 5 + 1 + 2 = 8, and 8^(3) = 512. Another example of a number with this property is 614656 = 28^(4).

We shall define a_(n) to be the nth term of this sequence and insist that a number must contain at least two digits to have a sum.

You are given that a_(2) = 512 and a_(10) = 614656.

Find a_(30).

Με java λύνεται σε 10-20 γραμμές και τρέχει πρακτικά ακαριαία, αρκεί να βρεθεί η πλάγια οδός…

Τώρα ξέρετε πως να περάσετε την ώρα σας στις βαρετές εορταστικές εκδηλώσεις (ρεβεγιόν κλπ). Επίσης, μην ξεχάσετε στο προφίλ σας να συμπληρώσετε τη χώρα, ώστε να προάγεται η άμιλλα μεταξύ των Ελλήνων. Προσπαθώ (jkoza) να λύσω ακόμα 1 πρόβλημα για να ανέβω στη 13η θέση και έχω κολλήσει!!

hint: Στο αρχικό άρθρο μην παραλείψετε να τσεκάρετε την ιδέα No 11.

Ζήτω η παράνοια!

Posted in programming on 17 Νοεμβρίου 2008 by mathpoet

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

Μια άποψη με την οποία πιθανά θα συμφωνήσουν οι περισσότεροι, λέει ότι ο προγραμματισμός σε ασκεί στην επίλυση προβλημάτων. Η δουλειά του προγραμματιστή πολύ συχνά είναι αυτό ακριβώς. Αν δεν ανήκει στην κατηγορία των επί χρήμασι μαϊμούδων (code monkey), προσπαθεί να συνδυάσει κατάλληλα τα διαθέσιμα στοιχεία μιας εργαλειοθήκης, ώστε να πετύχει ένα συγκεκριμένο στόχο. Όσοι αρέσκονται στο σπορ, όταν πετυχαίνουν το στόχο νιώθουν κάπως σαν το παιδάκι που συναρμολόγησε ένα κάστρο με τουβλάκια lego ή σαν τον Μαγκάιβερ που μόλις χρησιμοποίησε τον κινητήρα jet που κατασκεύασε από ένα κουτί σπίρτα, ένα γρύλο αυτοκινήτου και μισό κιλό μπάμιες (αφήνεται ως άσκηση για τον αναγνώστη). Μετά από λίγη εξάσκηση όμως, ο προγραμματιστής καταλαβαίνει ότι δεν φτάνουν οι ικανότητες του Μαγκάιβερ. Το πρώτο βήμα είναι να μελετήσει διεξοδικά το ίδιο το πρόβλημα. Ποια είναι τα δεδομένα, ποιες οντότητες εμπλέκονται, είναι ξεκάθαρος ο στόχος,…; Αν ξεκινήσω χωρίς αυτές τις απαντήσεις, ακόμα κι αν καταφέρω να φτιάξω κάτι, απλά θα είναι άχρηστο. Επίσης, αν θέλω να φτιάξω κάτι μεγάλο, δεν είναι δυνατό να απαντήσω σε όλες αυτές τις ερωτήσεις ούτε να κάνω τα μαγικά μου στο συνολικό πρόβλημα. Υποχρεωτικά θα ψάξω για υποπροβλήματα που μπορώ να αντιμετωπίσω και σιγά – σιγά θα χτίσω την απόλυτη λύση. Προφανώς όλοι οι άνθρωποι περίπου έτσι αντιμετωπίζουμε τα όποια προβλήματα προκύπτουν σε πολλούς τομείς και ο προγραμματισμός είναι μια καλή προπόνηση.

Θέλω όμως να συζητήσω μια άλλη πτυχή που σχετίζεται άμεσα με την προηγούμενη, αλλά δεν αναφέρεται συχνά και νομίζω έχει ενδιαφέροντα αποτελέσματα. Ο προγραμματιστής αφιερώνει ένα μεγάλο μέρος του χρόνου του, τόσο πριν όσο και μετά την ολοκλήρωση της εφαρμογής, στην απεντόμωση (debugging). Δηλαδή, στην διόρθωσή των σφαλμάτων που εξ ορισμού κάθε πρόγραμμα περιέχει. Οι περισσότεροι χρήστες Η/Υ, κάποια στιγμή καταράστηκαν τον προγραμματιστή, μια εταιρεία, την τύχη τους κτλ γιατί ταλαιπωρήθηκαν από κάποιο bug. Αυτό που λίγοι δυστυχώς γνωρίζουν, είναι ότι τα bugs μπορεί να έχουν πολύ μεγάλο υλικό κόστος και όχι μόνο. Τα bugs είναι πολλών ειδών και υπάρχουν για πολλούς λόγους, αλλά εδώ με ενδιαφέρει μια περίπτωση η οποία είναι πολύ συνηθισμένη, ειδικά όταν ο προγραμματιστής είναι νέος. Αναφέρομαι στις (λάθος) υποθέσεις που κάνει κάποιος όταν προγραμματίζει/λύνει ένα πρόβλημα. Για να μην το τραβήξω, θα αναφέρω ένα χαρακτηριστικό παράδειγμα. Κάποτε κλήθηκα να βρω το bug σε ένα πρόγραμμα που έπρεπε να υπολογίζει κάτι ανάλογα με τη χρονική διάρκεια μιας διαδικασίας. Το μελέτησα λίγο και είδα ότι με βάση το 24ωρο κάθε ημέρας, οι υπολογισμοί ήταν σωστοί. Η πρώτη μου σκέψη δηλαδή, ήταν ότι δεν υπάρχει πρόβλημα. Σύντομα όμως κατάλαβα ότι αυτή η τόσο κοινή υπόθεση, είναι λάθος. Όπως συμβαίνει και σε άλλες χρονικές ζώνες, μια ημέρα το χρόνο διαρκεί 23 ώρες και μια άλλη 25. Αυτό το φαινόμενο στον προγραμματισμό είναι πολύ συνηθισμένο και δεν σχετίζεται μόνο με bugs. Για παράδειγμα σε πολλές περιπτώσεις, λάθος υποθέσεις οδήγησαν σε λάθος σχεδιασμό. «Κανένας δεν πρόκειται να χρειαστεί πάνω από 640KB RAM…»

Είναι και εδώ εμφανές ότι το θέμα σχετίζεται με όλες τις επιστήμες, τη λογική και τη φιλοσοφία γενικότερα. Τι συμβαίνει όμως σε αυτόν που εκπαιδεύεται καθημερινά σε αυτό; Προφανώς αν αρχίσει να συμπεριφέρεται αντίστοιχα στη ζωή του, θα αποφύγει πολλές παγίδες που βασίζονται σε λάθος κοινές παραδοχές και δεν θα δέχεται αβασάνιστα ότι του λέει ο δάσκαλος, προϊστάμενος, δημοσιογράφος κλπ. Όταν όμως αμφισβητείς ανοιχτά τόσα πολλά πράγματα, έχεις πρόβλημα. Καταρχήν ανακαλύπτεις ότι οι πολλές ιδέες και απόψεις, δεν έχουν σοβαρό στήριγμα. Δυσκολεύεσαι να συζητήσεις με ανθρώπους που προβάλουν επιχειρήματα του στυλ «μα έτσι είναι», «έτσι κάνουν όλοι»,… και ανακαλύπτεις ότι όλοι συχνά ή σπάνια συμπεριφερόμαστε κάπως έτσι. Διαβάζεις ένα άρθρο ή δοκίμιο, βλέπεις ένα ωραίο ντοκιμαντέρ και στο τέλος σκέφτεσαι «εξαιρετικό, αλλά ας είμαι επιφυλακτικός γιατί δεν ξέρω αν ο συγγραφέας έχει μελετήσει αρκετά, ούτε αν από λάθος ή εσκεμμένα παρουσίασε τη μισή αλήθεια». Καλωσόρισες παράνοια…

Παρά τη μικρή παρενέργεια, αυτό νομίζω ότι είναι το πιο σημαντικό μάθημα που παίρνουμε από όλες τις θετικές επιστήμες.

ΥΓ: Εννοείται ότι όλα αυτά που διαβάζετε εδώ, δεν θα τα παίρνετε τοις μετρητοίς. Ακόμα κι εγώ που τα γράφω, διατηρώ τις επιφυλάξεις μου 😀