[C] - Minesweeper clone

[migf1]

 

Αχά! Άρα χρησιμοποιεί Win32 api ε; Τι λέει τότε πως είναι cross-platform ο κώδικας, μας κοροϊδεύει (ίσως δεν το κατάλαβα εγώ καλά).

 

Btw, μιας κι έχεις δει τα βίντεο, τελικά χρησιμοποιεί μονάχα C ή C++ (χρησιμοποιεί π.χ. C++ κλάσεις; )

 

 

[imitheos]

Αλλά δεν(προσωπικά πάντα) μου είναι και τόσο χρήσιμο για κάτι που φτιάχνω μονος μου και είναι τόσο μικρό όσο ο ναρκαλιευτής.

Είναι υποκειμενικό φυσικά αλλά δεν έχει σχέση ο όγκος του project ή αν το φτιάχνεις μόνος σου. Εφόσον το overhead ενός DVCS είναι τόσο αμελητέο, δεν υπάρχει λόγος να μην το χρησιμοποιήσει κάποιος (αν μιλάμε για κάποιο μικρό project και δεν σε ενδιαφέρει και τόσο η "καλή" ιστορία, τότε μιλάμε για μία παραπάνω εντολή (git commit -a -m "τάδε") στην workflow σου). Προσωπικά χρησιμοποιώ git ακόμη και για ένα προσωρινό project που αργότερα θα πετάξω. Και μόνο που μπορώ να γυρίσω πίσω σε οποιαδήποτε έκδοση και να δω κάτι που θέλω, φτάνει για να το χρησιμοποιήσω.

 

Πώς ακριβώς θα βοηθούσε το source control στο να δούμε τι φταίει vs αν ήταν ο κώδικας σκέτος ανεβασμένος κάπου;

Αν το bug εισήχθη από κάποιο σημείο και μετά και γνωρίζεις ότι το τάδε snapshot δούλευε σωστά, τότε με bisect (δυαδική αναζήτηση) θα βρεις πολύ γρήγορα σε ποιο commit εισήχθη το bug. Με σκέτο zip έχεις μόνο το τελευταίο snapshot στα χέρια σου οπότε θα πρέπει να κοιτάξεις όλο το κώδικα για να εντοπίσεις το λάθος. Ή να πάρεις 2-3 zip εκδόσεων και να κάνεις diff χειροκίνητα για να δεις τις αλλαγές αλλά και πάλι θα έχεις να ελέγξεις πολύ περισσότερο κώδικα από ό,τι ένα μόνο commit.

 

Εκτός ότι με την bisect δεν θα κοιτάξεις καθόλου τον κώδικα χειροκίνητα και θα σου πετάξει κατευθείαν το commit, αν το bug μπορεί να γίνει trigger με αυτοματοποιημένο τρόπο (πχ κάποιο script), τότε το πράγμα γίνεται ακόμη πιο εύκολο και δεν θα χρειαστεί να τρέξεις τίποτα.

 

Εγώ είμαι μαζί σου για το Git! Μην μασάς!

 

Btw, ο τύπος που μας έδωσες το link, κι αυτός δικός μας είναι . Ούτε καν make δεν χρησιμοποιεί ... έτσι! Αντίσταση

 

Είδα το 1ο του βίντεο. Δουλεύει command-line, edit με emacs, compile με ένα σκέτο batch file με το cl του VS και debug με το ide του vs (που κι αυτό από command-line to καλεί). Αρχηγός

 

ΥΓ. Μόνο που αντί για TCHAR καλεί directly τα ANSI functions του win32 api

Και ο Δελαπόρτας δικός σας είναι. Zip το καλύτερο. Τι git και μ.κίες τώρα.

 

Παρεμπιπτόντως έχω ένα 386DX/40 με DOS, γνήσιο PKZIP της PKWare και γνήσια Turbo C. Μπορώ να σας το δώσω να κάνετε τη δουλειά σας. Το ανταλλάσσω με ένα 4πύρηνο i5

 

 

Αντίσταση στα "το κάνουμε για να το κάνουμε, χωρίς να υπάρχει ουσιαστικός λόγος".

Σου κάνω τη χάρη και κάνω πως δεν το διάβασα αυτό για τα VCS, ειδικά από κάποιον που προγραμματίζει χρόνια και ειδικά σε C που η εισαγωγή μιας απλής γραμμής κώδικα ή ενός δείκτη μπορεί πάρα πολύ εύκολα να οδηγήσει σε UB και να πηδήξει ολόκληρο το πρόγραμμα (και αυτό να γίνει αντιληπτό 8 μήνες μετά και αφού έχουν γίνει 4000 αλλαγές).

[migf1]

@imitheos: Όλα αυτά για τον κλώνο του ναρκαλιευτή; Ουσιαστικός λόγος indeed!
 

Σχετικά με τα ειρωνικά σχόλια, λέω να τα κάνεις forward στον τύπο του handmade hero και να του προτείνεις τα ίδια. Είμαι σίγουρος πως θα χαρεί να παρατήσει το δικό του και να υιοθετήσει το δικό σου workflow, ακόμα και όταν γράφει "hello world". Άλλωστε πρόκειται για ακόμα έναν παλαιολιθικό νουμπά που δεν έχει επαφή με την πραγματικότητα.
 

https://handmadehero.org/

Who are you?
I am Casey Muratori, a Seattle-area game programmer. I spent many years in the industry working on popular game technology libraries, so you can currently find my code in literally thousands of games (partial lists here and here).

 

http://mollyrocket.com/casey/about.html

 

I grew up in rural Massachusetts, and have spent the entirety of my adult life in Seattle, Washington. I currently live downtown with my wife Ginger.

 

I am a lifetime software engineer, having learned to type about the same time I learned to write. I have been programming computers since I was seven years old, and still do at least one major software engineering project every year. I am now officially a “grumpy old man”, and you will often hear me complain about how the current generation of programmers has hardware that runs hundreds of times faster than what I grew up with, yet still writes software that runs at half the speed, or worse.

 

The most significant project I’ve created to date has been The Granny Animation SDK, a complete animation pipeline system that I first shipped in 1999 and which, 15 years later, still is in active use at many top-tier game studios. More recently, I worked with Jeff Roberts and Fabian Giesen to develop Bink 2, RAD Game Tools’s next generation video compression technology, and I rewrote the movement system and helped extend the world editor for Jonathan Blow’s upcoming game The Witness.

 

 

 

[bnvdarklord]

@imitheos Όπως είπες είναι υποκειμενικό.

 

Αλλά κάποια points:

 

 

 

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

 

Τα πλεονεκτήματα του git σε αυτές τις περιπτώσεις προσωπικά δεν μου φαίνονται και τόσο σημαντικά. Αν έχεις σοβαρό debugger δεν είναι πολύ δύσκολο ούτε χρονοβόρο να βρείς το σημείο που έχει πρόβλημα. Ο κώδικας είναι μικρός εξάλλου. Και το ότι τον δουλεύεις μόνος σου που είπα σημαίνει ότι ξέρεις που είναι τι.

 

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

 

 

[imitheos]

Ρε συ migf1 πρέπει να γίνεις κυβερνητικός εκπρόσωπος. Πώς γίνεται πάντα να παίρνεις αυτά που λέει κάποιος να τα διαστρευλώνεις και να τους δίνεις ό,τι διάσταση σε βολεύει.

 

@imitheos: Όλα αυτά για τον κλώνο του ναρκαλιευτή; Ουσιαστικός λόγος indeed!

Όταν ακόμη και στο κλώνο του ναρκαλιευτή υπάρχει περίπτωση να σε βοηθήσει χωρίς να σου προσθέτει κάποιο (σοβαρό) overhead ή μειονέκτημα ή ποιος ξέρει τι, ποιος θα ήταν ο ουσιαστικός λόγος να το χρησιμοποιήσεις ?

 

Σχετικά με τα ειρωνικά σχόλια, λέω να τα κάνεις forward στον τύπο του handmade hero και να του προτείνεις τα ίδια. Είμαι σίγουρος πως θα χαρεί να παρατήσει το δικό του και να υιοθετήσει το δικό σου workflow, ακόμα και όταν γράφει "hello world". Άλλωστε πρόκειται για ακόμα έναν παλαιολιθικό νουμπά που δεν έχει επαφή με την πραγματικότητα.

Δεν θυμάμαι να ειρωνεύτηκα τον τύπο του hh ούτε να ζήτησα από κάποιον να αλλάξει το workflow του. Και να χρησιμοποιήσει κάποιος git και αν δεν χρησιμοποιήσει εμένα το ίδιο μου κάνει. Δεν θα χάσω τον ύπνο μου. Υποτίθεται ότι επιχειρηματολογούμε σε ένα φόρουμ. Μπορείς να επιχειρηματολογήσεις κατά των VCS και να μην προσπαθείς να το πας αλλού ?

[defacer]

Είναι γνωστό ότι ο migf1 δε φοράει παρωπίδες και διατηρεί όλα τα ενδεχόμενα ανοιχτά για να βρει την καλύτερη λύση για την κάθε περίπτωση. Θέλεις να πας βόλτα; Γιατί να φορέσεις ντε και καλά παπούτσια; O "νουμπάς" Abebe Bikila κέρδισε χρυσό στο μαραθώνιο τρέχοντας ξυπόλητος, γλυτώνοντας το overhead να λύνει και να δένει τα κορδόνια που κάποιοι κολλημένοι το έχουν σαν ευαγγέλιο. 

 

@bnvdarklord, για το πώς θα βοηθούσε το source control να βρούμε το πρόβλημά σου: αυτό που είχα στο μυαλό μου είναι ότι πρώτα απ' όλα θα βοηθούσε γιατί έχοντας ας πούμε μια υποψία όπως εγώ όταν διάβασα το "bug report" θα ήταν πανεύκολο με μερικά κλικ να πάω github να δω source και να την επιβεβαιώσω ή να την αποκλείσω. Σαφώς θα μπορούσες να δημοσιοποιήσεις τον κώδικα και αλλιώς (zip καλή ώρα) αλλά το github είναι όχι μόνο άπειρα βολικότερο αλλά έχει και πολύ μικρότερο overhead.

 

ΥΓ να σημειώσω ότι σε προϊστορικές εποχές (2003) που είχα ξεκινήσει να ασχολούμαι με το Moodle, ο κώδικας ήταν σε CVS και βέβαια δεν έπαιρνε ο κάθε τυχαίος write access έτσι απλά. Στην αρχή λοιπόν αυτό που γινόταν ήταν κυριολεκτικά upload zip στο forum (εξάλλου τότε δεν είχα χρησιμοποιήσει ποτέ κάποιο VCS οπότε δεν ήξερα και καλύτερα), την άλλη μέρα διαβάζεις το feedback, development, upload ξανά κλπ κλπ. Σε κάποια φάση αν τύχει να μπλεχτεί και άλλος τότε manually "sync" τη δουλειά του ενός με του άλλου πριν από κάθε "release" κλπ. Από τη μια αυτό το workflow δούλεψε. Από την άλλη πριν βγουν τα αυτοκίνητα και ο αραμπάς μια χαρά δούλευε.

[bnvdarklord]

@bnvdarklord, για το πώς θα βοηθούσε το source control να βρούμε το πρόβλημά σου: αυτό που είχα στο μυαλό μου είναι ότι πρώτα απ' όλα θα βοηθούσε γιατί έχοντας ας πούμε μια υποψία όπως εγώ όταν διάβασα το "bug report" θα ήταν πανεύκολο με μερικά κλικ να πάω github να δω source και να την επιβεβαιώσω ή να την αποκλείσω. Σαφώς θα μπορούσες να δημοσιοποιήσεις τον κώδικα και αλλιώς (zip καλή ώρα) αλλά το github είναι όχι μόνο άπειρα βολικότερο αλλά έχει και πολύ μικρότερο overhead.

Ναι κατάλαβα, δεν έχεις άδικο. Όπως λες και εσύ βολεύει κυρίως αν χρειαστεί να δημοσιευτεί ο κώδικας. Μιας και είμαι άπειρος ακόμα και δεν έχω δουλέψει τόσο σε projects με άλλα άτομα δεν το σκέφτομαι έτσι όταν φτιάχνω κάτι για μένα Αν καταλαβαίνω καλά πάντως νομίζω δεν διαφωνείς ότι σε κάτι μικρό που θα έβλεπα μόνο εγώ δεν προσφέρει και τόσα πολλά.

[Kercyn]

Και να μπεις από νωρίς στο κλίμα του να γράφεις ωραία μηνύματα εξηγώντας τι κάνεις (άσχετα αν "εισάγει overhead στον προγραμματιστή").

 

Είναι κρίμα να βλέπεις repos με commits "initial add" -> "update tree" -> "update tree again".

 

 

 

Να κάνω λίγο hijack το thread γιατί έχω μια απορία γι' αυτό. Καταλαβαίνω τι λες για τα μηνύματα αλλά αυτό που δεν καταλαβαίνω είναι πώς μοιάζει ένα "σωστό" commit μήνυμα. Εγώ ξεκίνησα να χρησιμοποιώ το bitbucket για την πτυχιακή μου, κυρίως για να μάθω μερικά πράγματα για τα VCS. Πολλές φορές κάνω push πολλά αρχεία τα οποία έχουν μικρές αλλαγές από προηγούμενες εκδόσεις. Τι ακριβώς θα πρέπει να γράφω στα μηνύματα; Την κάθε μικρή αλλαγή που έκανα σε όλα τα αρχεία; Μερικές φορές οι αλλαγές είναι της τάξεως της μίας γραμμής, για να διορθώσω ή να βελτιώσω κάτι μικρό.

 

 

[bnvdarklord]

 

 

Να κάνω λίγο hijack το thread γιατί έχω μια απορία γι' αυτό. Καταλαβαίνω τι λες για τα μηνύματα αλλά αυτό που δεν καταλαβαίνω είναι πώς μοιάζει ένα "σωστό" commit μήνυμα. Εγώ ξεκίνησα να χρησιμοποιώ το bitbucket για την πτυχιακή μου, κυρίως για να μάθω μερικά πράγματα για τα VCS. Πολλές φορές κάνω push πολλά αρχεία τα οποία έχουν μικρές αλλαγές από προηγούμενες εκδόσεις. Τι ακριβώς θα πρέπει να γράφω στα μηνύματα; Την κάθε μικρή αλλαγή που έκανα σε όλα τα αρχεία; Μερικές φορές οι αλλαγές είναι της τάξεως της μίας γραμμής, για να διορθώσω ή να βελτιώσω κάτι μικρό.

 

 

 

 

Εγώ σε τετοιες περιπτώσεις έγραφα "minor changes about a, b and c"

 

 

[migf1]

 

 

...

Και ο Δελαπόρτας δικός σας είναι. Zip το καλύτερο. Τι git και μ.κίες τώρα.

Παρεμπιπτόντως έχω ένα 386DX/40 με DOS, γνήσιο PKZIP της PKWare και γνήσια Turbo C. Μπορώ να σας το δώσω να κάνετε τη δουλειά σας. Το ανταλλάσσω με ένα 4πύρηνο i5

...

 

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

 

 

Για τα VCS έχω επιχειρηματολογήσει άπειρες φορές. Είναι πάρα πολύ χρήσιμα σε μεσαίο-μεγάλα projects shared among devs/users και σχεδόν άχρηστα σε ελαχιστο-μικρά πρότζεκτ ενός ανθρώπου (με όλες τις ενδιάμεσες διακυμάνσεις).

 

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

 

 

 

Να κάνω λίγο hijack το thread γιατί έχω μια απορία γι' αυτό. Καταλαβαίνω τι λες για τα μηνύματα αλλά αυτό που δεν καταλαβαίνω είναι πώς μοιάζει ένα "σωστό" commit μήνυμα. Εγώ ξεκίνησα να χρησιμοποιώ το bitbucket για την πτυχιακή μου, κυρίως για να μάθω μερικά πράγματα για τα VCS. Πολλές φορές κάνω push πολλά αρχεία τα οποία έχουν μικρές αλλαγές από προηγούμενες εκδόσεις. Τι ακριβώς θα πρέπει να γράφω στα μηνύματα; Την κάθε μικρή αλλαγή που έκανα σε όλα τα αρχεία; Μερικές φορές οι αλλαγές είναι της τάξεως της μίας γραμμής, για να διορθώσω ή να βελτιώσω κάτι μικρό.

 

 

 

Θεωρητικά δεν κάνεις commit αν δεν μαζευτεί ικανός αριθμός αλλαγών.

[kagelos]

Για utilities / δοκιμες των 100 - 200 γραμμών που δεν θα χρησιμοποιηθούν ποτέ, εγώ δεν χρησιμοποιώ VCS. Από αυτά όμως, τελικά ο κώδικας μπορεί να καταλήξει σε μεγαλύτερο project το οποίο έχει VCS.

 

Τώρα αν για project του αποκλειστικά ενός ατόμου χρειάζεται VCS, η απάντηση είναι σαφώς και ναι. Αν θες να δουλέψεις σε bug fixes, αλλαγές, πειράματα κλπ. σε ένα σύστημα το οποίο κάπου παίζει live και μπορεί ανά πάσα στιγμή να χρειαστεί να κάνεις ένα update, χωρίς να έχεις τελειώσει αυτά που έκανες, τι θα κάνεις;

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

 

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

[defacer]

Αν καταλαβαίνω καλά πάντως νομίζω δεν διαφωνείς ότι σε κάτι μικρό που θα έβλεπα μόνο εγώ δεν προσφέρει και τόσα πολλά.

 

Για κάποιο ορισμό του "μικρού" και αν αναφερόμαστε μόνο στις "άμεσες" λειτουργίες του source control ναι δε διαφωνώ (αλλά πιθανώς ο δικός μου ορισμός να σημαίνει μικρότερο απ' ότι ο δικός σου).

 

Εκτός όμως από την περίπτωση να κάνεις "λάθος" στον ορισμό του μικρού υπάρχουν και άλλα πράγματα που μετράνε:

• Πρώτα απ' όλα δε μπορείς να βάλεις versioning εκ των υστέρων. Επομένως γιατί να πάρει κανείς το ρίσκο να ξεπεράσει το υποτιθέμενο ιδανικό σημείο από το οποίο και μετά χρειάζεται source control επειδή δεν το αναγνώρισε εκείνη τη στιγμή; git init git commit και απο κει και πέρα κάνε commit όσο συχνά νομίζεις. Είναι σημαντικό και μόνο το ότι ξέρεις πως κυριολεκτικά ανα πάσα στιγμή έχεις στη διάθεσή σου όλες τις δυνατότητες.
• Μια υποπερίπτωση του παραπάνω που είναι πολύ σημαντική και γι' αυτό παίρνει bullet μόνη της: κανείς δε μπορεί να φανταστεί τι θα συμβεί αύριο με το project που ξεκινάει σήμερα.
• Υπάρχουν και τα έμμεσα πλεονεκτήματα επειδή τα DVCS δεν είναι πλέον το σκέτο εργαλείο αλλά ολόκληρο οικοσύστημα. Τα ανεβάζεις online (μ' αυτό τον τρόπο διατηρείς και "backup" για αστεία projects που υπο ΚΣ θα τα έτρωγε μαύρο φίδι κάποια στιγμή), μπορεί ο άλλος να κάνει fork και να στείλει pull request χωρίς πολλά πολλά, κλπ κλπ.
• Όταν έρθει η ώρα να χρησιμοποιήσεις VCS σε σοβαρό project, η ποιότητα της χρήσης που θα κάνεις θα εξαρτάται από την εμπειρία που έχεις. Με τη λογική του ότι σε μη σοβαρό project δε χρειάζεται πας ξεβράκωτος στ' αγγούρια.

   

   

  π.χ. για το Moodle, κάποια στιγμή μου δόθηκε write access στο CVS και... έτρεχα να διαβάσω το red bean book για να δω τι είναι αυτό και πώς χρησιμοποιείται. Ταυτόχρονα σκεφτόμουν θεέ μου πόσο ρόμπα.   

   

[bnvdarklord]

Συμφωνώ με αυτά που λες. Και ναι τωρα που το λες απο το να το βαζω backup στο dropbox καλύερα να ειναι σε ενα bitbucket πχ.

[defacer]

Εγώ σε τετοιες περιπτώσεις έγραφα "minor changes about a, b and c"

 

Δε θέλω να είμαι απόλυτος αλλά γενικά το "minor changes" δε βοηθάει. Αν είναι non-functional changes τότε πες reformatting/cleanup/whatever. Αν είναι functional τότε πες τι ακριβώς άλλαξε (έστω και πολύ συνοπτικά).

[migf1]

Συμφωνώ με αυτά που λες. Και ναι τωρα που το λες απο το να το βαζω backup στο dropbox καλύερα να ειναι σε ενα bitbucket πχ.

 

Δεν διαβάζεις backups manually όταν δεν χρησιμοποιείς vcs. Κάνεις diff στα backups (τα οποία ούτε αυτά τα κρατάς manually, αλλά automated). Ακόμα κι αυτό όμως είναι μάλλον άχρηστο για πολύ μικρά projects, γιατί πας απευθείας στον debugger. Επίσης, αν έχεις αναπτύξει τεχνικές κώδικα όπως για παράδειγμα αυτή που ο Μουρατόρι χαρακτηρίζει compression programming, ελαχιστοποιείς τις πιθανότητες για bugs (προφανώς χωρίς να της εξαλείφεις ποτέ).

 

Όσο μεγαλώνει όμως το project σου, από ένα σημείο και μετά δεν σε καλύπτει ούτε το backup/diff... εκεί πλέον γίνεται πολύ πιο χρήσιμο, έως απαραίτητο, το vcs.

 

Με λίγα λόγια, "παν μέτρο άριστο", ανάλογα την περίσταση.