Discussione: [1]Pillole di "Programmazione" & Link Utili

panzone

#451 18-08-15 23:43

---

pasquale7bellezze

Sinceramente non so a cosa ti riferisci.

Il problema dell' observer è: tu hai tot entità, probabilmente asincrone, che generano dei dati. Come fai ad "osservarli", ovvero ad ottenere i loro dati (che può essere anche una cosa banale eh, tipo "l' utente ha premuto il tasto w sulla tastiera", non sto parlando di cose fuori dal mondo) ?

1) Il metodo che chiunque penserebbe è: continuo ad interrogare le entità in un ciclo e aspetto mi diano roba (nell' esempio sopra, continuo ad interrogare la tastiera finché l' utente non preme w). Il problema di questo metodo è che quindi l' osservatore perde un casino di tempo e risorse continuando ad interrogare le entità e risulta difficile estenderlo con nuove entità (inserire un if è fuori discussione )
2) Soluzione 2: facciamo che siano le unità ad avvisarmi quando han un dato. Possibile, ma resta il problema che quindi le entità devon essere a conoscenza dell' osservatore e di come è fatto (problema enorme di riutilizzo di codice).

Il pattern Observer ci dice che la soluzione 2 è una buona idea, con un paio di correzioni. L' idea è che le entità avvisino gli osservatori, ma che a loro volta gli osservatori sono assolutamente trasparenti agli osservati. In UML l' idea è questa:

https://upload.wikimedia.org/wikiped...d/Observer.svg

Spoiler:

Capisco che potresti vederli solo come seghette mentali, ma son un ottimo modo per diventare uno sviluppatore in grado di grado di scrivere buon codice

pasquale7bellezze

Hai risorse/testi in mente?

Il terzo libro che ti ho consigliato. Scrum è praticamente metodologia agile sotto un' altro nome

Master94ga

#452 18-08-15 23:47

---

panzone

Il problema dell' observer è: tu hai tot entità, probabilmente asincrone, che generano dei dati. Come fai ad "osservarli", ovvero ad ottenere i loro dati (che può essere anche una cosa banale eh, tipo "l' utente ha premuto il tasto w sulla tastiera", non sto parlando di cose fuori dal mondo) ?

1) Il metodo che chiunque penserebbe è: continuo ad interrogare le entità in un ciclo e aspetto mi diano roba (nell' esempio sopra, continuo ad interrogare la tastiera finché l' utente non preme w). Il problema di questo metodo è che quindi l' osservatore perde un casino di tempo e risorse continuando ad interrogare le entità e risulta difficile estenderlo con nuove entità (inserire un if è fuori discussione )
2) Soluzione 2: facciamo che siano le unità ad avvisarmi quando han un dato. Possibile, ma resta il problema che quindi le entità devon essere a conoscenza dell' osservatore e di come è fatto (problema enorme di riutilizzo di codice).

Il pattern Observer ci dice che la soluzione 2 è una buona idea, con un paio di correzioni. L' idea è che le entità avvisino gli osservatori, ma che a loro volta gli osservatori sono assolutamente trasparenti agli osservati. In UML l' idea è questa:

https://upload.wikimedia.org/wikiped...d/Observer.svg

Spoiler:

Capisco che potresti vederli solo come seghette mentali, ma son un ottimo modo per diventare uno sviluppatore in grado di grado di scrivere buon codice

Il terzo libro che ti ho consigliato. Scrum è praticamente metodologia agile sotto un' altro nome

Codice:

document.onkeypress = function (e) {
    e = e || window.event;

    if (e.keyCode == "43")
    {
       code
    }
}

In js io ho usato codice del genere, quindi quale dei due metodi ho utilizzato? Credo il primo, e per utilizzare observer come dovrei fare?

Affa

#453 18-08-15 23:54

---

Master94ga

Codice:

document.onkeypress = function (e) {
    e = e || window.event;

    if (e.keyCode == "43")
    {
       code
    }
}

In js io ho usato codice del genere, quindi quale dei due metodi ho utilizzato? Credo il primo, e per utilizzare observer come dovrei fare?

Hint: niente numeri magici, 43 non vuol dire nulla.

Sai cosa stai facendo con quel ||?

JS usa il concetto di listener, quello di cui parla Panzone nel tuo caso è già integrato nel linguaggio.

Yay!

Master94ga

#454 18-08-15 23:58

---

Affa

Hint: niente numeri magici, 43 non vuol dire nulla.

Sai cosa stai facendo con quel ||?

JS usa il concetto di listener, quello di cui parla Panzone nel tuo caso è già integrato nel linguaggio.

Yay!

Il 43 indica un tasto della tastiera che in questo momento non mi ricordo esattamente quale, come pensavo è già integrato nel linguaggio

No, cosa indicano le "| |"?

Affa

#455 19-08-15 00:08

---

Master94ga

Il 43 indica un tasto della tastiera che in questo momento non mi ricordo esattamente quale, come pensavo è già integrato nel linguaggio

No, cosa indicano le "| |"?

Ecco appunto. So anche io che quel numero è un tasto, ma non ho la tabella in memoria. Tu stesso che hai scritto il codice ammetti di non ricordartelo, non va affatto bene: pensa a un modo di scrivere nel codice di che tasto di tratta, e senza usare i commenti. Meno Magic numbers meno bestemmie.

Il || esemplifica quelli che secondo me sbagliano in tanti, e la colpa è in parte di Stack Overflow. Si cerca un problema su Google, si trova su SO la risposta e si copia il codice senza neanche prendersi il tempo di capire quelli che fa.

Vedo funzioni con snippet interi di codice addirittura non formattato presso da SO, e quando chiedo all'autore di spiegarmi che cavolo fa non me lo da spiegare "perché tanto funziona".

Non ce l'ho con te sia chiaro, ma il mio consiglio è di capire sempre ogni singola riga che hai nel codice, tanto da saperla spiegare. Perché questo modo di scrivere poi porta a workaround e hack al momento dell'aggiunta di altre funzionalità, e la cosa peggiora esponenzialmente fino a quando ti ritrovi con codebase talmente intrecciati che piuttosto che modificarli conviene riscriverli da zero.

Esempio: mi manca un unico esame per la laurea che prevede la scrittura di un'app per Android, in coppia. Purtroppo il codice l'ha scritti un mio compagno di corso, e ti giuro che se ci presentiamo con il source in quello stato il prof ci manda a fanculo diretti.

Quindi adesso oltre a dover finire la tesi devo anche riguardarmi tutto e probabilmente riscrivere tre quarti, perché è tutto un copia incolla di OS, il che porta a formattazioni diverse, lingue diverse, concetti diversi e tante bestemmie.

Yay!

pasquale7bellezze

#456 19-08-15 00:15

---

panzone

Il problema dell' observer è: tu hai tot entità, probabilmente asincrone, che generano dei dati. Come fai ad "osservarli", ovvero ad ottenere i loro dati (che può essere anche una cosa banale eh, tipo "l' utente ha premuto il tasto w sulla tastiera", non sto parlando di cose fuori dal mondo) ?

1) Il metodo che chiunque penserebbe è: continuo ad interrogare le entità in un ciclo e aspetto mi diano roba (nell' esempio sopra, continuo ad interrogare la tastiera finché l' utente non preme w). Il problema di questo metodo è che quindi l' osservatore perde un casino di tempo e risorse continuando ad interrogare le entità e risulta difficile estenderlo con nuove entità (inserire un if è fuori discussione )
2) Soluzione 2: facciamo che siano le unità ad avvisarmi quando han un dato. Possibile, ma resta il problema che quindi le entità devon essere a conoscenza dell' osservatore e di come è fatto (problema enorme di riutilizzo di codice).

Il pattern Observer ci dice che la soluzione 2 è una buona idea, con un paio di correzioni. L' idea è che le entità avvisino gli osservatori, ma che a loro volta gli osservatori sono assolutamente trasparenti agli osservati. In UML l' idea è questa:

https://upload.wikimedia.org/wikiped...d/Observer.svg

Spoiler:

Capisco che potresti vederli solo come seghette mentali, ma son un ottimo modo per diventare uno sviluppatore in grado di grado di scrivere buon codice

No anzi mi appare tutt'altro che banale, l'hai spiegato bene.

Il terzo libro che ti ho consigliato. Scrum è praticamente metodologia agile sotto un' altro nome

Le 600 pagine mi spaventano. Sono anche in una situazione che mi devo "dare una mossa" con la programmazione. È qualcosa questo o c'è altro che può andare bene nel frattempo che studio un po' i linguaggi e provo a scrivere?

panzone

#457 19-08-15 00:27

---

Master94ga

Codice:

document.onkeypress = function (e) {
    e = e || window.event;

    if (e.keyCode == "43")
    {
       code
    }
}

In js io ho usato codice del genere, quindi quale dei due metodi ho utilizzato? Credo il primo, e per utilizzare observer come dovrei fare?

Rifacendoci al discorso di prima, sai che presentando questo codice dovrei considerarti abbastanza malamente come sviluppatore, si ?

1) Usi il codice ascii per identificare il tasto. Senza una tabella io non so minimamente cosa sia 43 (non è vero, son un figo e so essere il + (nelle ultime 3 settimane sto scrivendo più codice c ed assembly del normale ed Xcode ha il pessimo vizio di mostrarmi le variabili a 1 byte con il char, se stampabile)*)
2) Per gestire più tasti ovviamente avresti fatto un if immenso

Brr (Per il resto ti ha risposto affa)

Spoiler:

*anzi, se qualcuno sa come diavolo faccio a farmele mettere sempre in esadecimale diventa il mio migliore amico

pasquale7bellezze

No anzi mi appare tutt'altro che banale, l'hai spiegato bene.


Le 600 pagine mi spaventano. Sono anche in una situazione che mi devo "dare una mossa" con la programmazione. È qualcosa questo o c'è altro che può andare bene nel frattempo che studio un po' i linguaggi e provo a scrivere?

Metodologie di questo tipo in ogni caso le apprendi più sul campo che su libri. Io mi concentrerei sul migliorare le tue skill da sviluppatore (che non include solo studiare un po' di linguaggi. Imparare ad usare un SCM come git, imparare almeno i pattern più banali, imparare a scrivere codice ordinato son sicuramente più utili che leggerti 600 pagine su metodologie agili.

Master94ga

#458 19-08-15 10:13

---

Affa

Ecco appunto. So anche io che quel numero è un tasto, ma non ho la tabella in memoria. Tu stesso che hai scritto il codice ammetti di non ricordartelo, non va affatto bene: pensa a un modo di scrivere nel codice di che tasto di tratta, e senza usare i commenti. Meno Magic numbers meno bestemmie.

Il || esemplifica quelli che secondo me sbagliano in tanti, e la colpa è in parte di Stack Overflow. Si cerca un problema su Google, si trova su SO la risposta e si copia il codice senza neanche prendersi il tempo di capire quelli che fa.
Yay!

E' codice che ho scritto tanto tempo fa, e quando ci lavoravo avevo la tabella ascii a portata di mano, ma non la so a memoria. Per quanto riguarda scrivere nel codice di che tasto si tratta senza i commenti non mi viene in mente nulla...

Sul fatto di Stack Overflow sono d'accordo con te, non sapendo come fare una cosa è nornale cercare per una soluzione, ma ho sbagliato a non studiarmi come dici tu ogni riga di codice.

panzone

Rifacendoci al discorso di prima, sai che presentando questo codice dovrei considerarti abbastanza malamente come sviluppatore, si ?

1) Usi il codice ascii per identificare il tasto. Senza una tabella io non so minimamente cosa sia 43 (non è vero, son un figo e so essere il + (nelle ultime 3 settimane sto scrivendo più codice c ed assembly del normale ed Xcode ha il pessimo vizio di mostrarmi le variabili a 1 byte con il char, se stampabile)*)
2) Per gestire più tasti ovviamente avresti fatto un if immenso

Brr (Per il resto ti ha risposto affa)

1) Quanto lavoravo a quel codice usavo la tabella ovviamente, ma non la so a memoria.
2)Eh si, ho fatto un if immenso, quale altra soluzione avrei potuto utilizzare? Sono aperto ai consigli

Perchè sia tu che affa siete sfavorevoli ai commenti nel codice?
Che libro posso usare per migliorare il mio stile di programmazione e evitare di scrivere "brutto" codice?

panzone

#459 19-08-15 12:25

---

Master94ga

2)Eh si, ho fatto un if immenso, quale altra soluzione avrei potuto utilizzare? Sono aperto ai consigli

Dipende dal contesto, ma un trucchetto niente male è una chain of responsability oppure una jump table. Il problema del mega if è che è sia brutto da leggere, sia da comprendere, sia ammazzi le performance.

Perchè sia tu che affa siete sfavorevoli ai commenti nel codice?

Io non son totalmente sfavorevole ai commenti nel codice (mica son un XP programmer ). Il punto, e concordo con affa, è che il codice dovrebbe essere in grado di autocommentarsi da solo. Tu sopra puoi scrivere con un commento che 43 è +, ed ok, ma sarebbe molto meglio che tu non usassi il magic number e facessi fare al compilatore da solo la conversione (ora non so come javascript veda i caratteri e neanche mi interessa, ma in ogni linguaggio decente scrivere 43 o scrivere '+' è la stessa identica cosa (ps nota che usa la virgoletta, non le doppie virgolette), ma il secondo è estremamente più banale da capire, no ?)

Che libro posso usare per migliorare il mio stile di programmazione e evitare di scrivere "brutto" codice?

Potrei citarti un po' di libri ma al 99% è roba che apprendi con l' esperienza quando inizi a lavorare con codice che deve essere utilizzato da altri.

Master94ga

#460 19-08-15 14:41

---

Ho scritto questi due codici.
If-else

Spoiler:

Codice:

const Numbers = {
 zero: 48,
 one: 49,
 two: 50,
 three: 51,
 four: 52,
 five: 53,
 six: 54,
 seven: 55,
 eight: 56,
 nine: 57,
};


document.onkeypress = function (e) 
{
    e = e || window.event;
    console.log(e.keyCode);


    if (e.keyCode == Numbers.zero)
        console.log(0);
    else if (e.keyCode == Numbers.one)
        console.log(1);
    else if (e.keyCode == Numbers.two)
        console.log(2);
    else if (e.keyCode == Numbers.three)
        console.log(3);
    else if (e.keyCode == Numbers.four)
        console.log(4);
    else if (e.keyCode == Numbers.five)
        console.log(5);
    else if (e.keyCode == Numbers.six)
        console.log(6);
    else if (e.keyCode == Numbers.seven)
        console.log(7);
    else if (e.keyCode == Numbers.eight)
        console.log(8);
    else if (e.keyCode == Numbers.nine)
        console.log(9);


}

Switch-case

Spoiler:

Codice:

const Numbers = {
 zero: 48,
 one: 49,
 two: 50,
 three: 51,
 four: 52,
 five: 53,
 six: 54,
 seven: 55,
 eight: 56,
 nine: 57,
};


document.onkeypress = function (e) 
{
    e = e || window.event;
    console.log(e.keyCode);


    switch (e.keyCode) 
    {
        case Numbers.zero:
            console.log(0)
            break;
        
        case Numbers.one:
            console.log(1)
            break;


        case Numbers.two:
            console.log(2)
            break;


        case Numbers.three:
            console.log(3)
            break;


        case Numbers.four:
            console.log(4)
            break;


        case Numbers.five:
            console.log(5)
            break;


        case Numbers.six:
            console.log(6)
            break;


        case Numbers.seven:
            console.log(7)
            break;


        case Numbers.eight:
            console.log(8)
            break;


        case Numbers.nine:
            console.log(9)
            break;
    }
}

1) Ho usato i MagicalNumbers per rendere il codice più comprensibile e ora non ci sono numeri a caso che poi uno rischia di scordarsi
2) Le performance dovrebbero essere molto ma molto simile leggendo in rete e vedendo altri test, ma dipendono anche dal browser
Un libro trovare in rete fa queste considerazioni:

Use the if statement when:
-There are no more than two discrete values for which to test.
-There are a large number of values that can be easily separated into ranges.

Use the switch statement when:
-There are more than two but fewer than 10 discrete values for which to test.
-There are no ranges for conditions because the values are nonlinear.

3)Numbers è di tipo const e var perchè dato che il valore non cambia mai usando const si hanno migliori performance
4)Devo provare ancora "Chain of Responsability" e "Jump table" ma mi servirebbe un libro che spiega per bene questi design pattern per capirne il funzionamento, magari con qualche esempio

panzone

#461 19-08-15 15:52

---

Oppure, più banalmente, prendi li valore, gli togli 48 e stampi quello Niente if, niente switch, meno seghette mentali.

Sai vero che i caratteri della tastiera son numeri, si ? Se prendi il numero e ci togli 48 (o meglio, '0') ta dan: hai il numero da stampare senza if, switch e roba del genere. Easy.

Master94ga

1) Ho usato i MagicalNumbers per rendere il codice più comprensibile e ora non ci sono numeri a caso che poi uno rischia di scordarsi

Leggermente meglio, ma non è necessario quel numbers.

2) Le performance dovrebbero essere molto ma molto simile leggendo in rete e vedendo altri test, ma dipendono anche dal browser
Un libro trovare in rete fa queste considerazioni:

Use the if statement when:
-There are no more than two discrete values for which to test.
-There are a large number of values that can be easily separated into ranges.

Use the switch statement when:
-There are more than two but fewer than 10 discrete values for which to test.
-There are no ranges for conditions because the values are nonlinear.

In un caso del genere cambia una bega (oltre ad essere abbastanza discutibile ?)

3)Numbers è di tipo const e var perchè dato che il valore non cambia mai usando const si hanno migliori performance

Inifluente, il JIT in questo caso è ampiamente in grado di capirlo da solo (e se non ci riesce lol javascript)

Scrivere buon codice significa anche non farsi seghette mentali sulle performance quando non c' è necessità.

Spoiler:

Nota: noi non ci facciamo problemi per la catena di if per branch prediction e roba varia. Noi ci facciamo problemi perchè è una catena di if ed è una cosa estremamente ingestibile a lungo andare

4)Devo provare ancora "Chain of Responsability" e "Jump table" ma mi servirebbe un libro che spiega per bene questi design pattern per capirne il funzionamento, magari con qualche esempio

Design Patterns, il libro che ho consigliato sopra, è il testo che storicamente ha introdotto il concetto di pattern.

Master94ga

#462 19-08-15 16:08

---

panzone

Oppure, più banalmente, prendi li valore, gli togli 48 e stampi quello Niente if, niente switch, meno seghette mentali.

Sai vero che i caratteri della tastiera son numeri, si ? Se prendi il numero e ci togli 48 (o meglio, '0') ta dan: hai il numero da stampare senza if, switch e roba del genere. Easy.

Sisi, ma in questo caso può andare bene ma in generale alla pressione del tasto fa qualche azione e non semplicemente la stampa quindi non posso rimuovere if o switch. E lo posso fare in questo caso che sono numeri, in caso di simboli no.

Leggermente meglio, ma non è necessario quel numbers.

In che senso?

Inifluente, il JIT in questo caso è ampiamente in grado di capirlo da solo (e se non ci riesce lol javascript)
Scrivere buon codice significa anche non farsi seghette mentali sulle performance quando non c' è necessità.

Se lo riconosce automaticamente che senso ha allora usare const al posto di var o viceversa?
http://stackoverflow.com/questions/2...s-it-necessary

Design Patterns, il libro che ho consigliato sopra, è il testo che storicamente ha introdotto il concetto di pattern.

Ottimo
E' questo? http://www.amazon.it/Design-Patterns.../dp/0201633612

Affa

#463 19-08-15 18:08

---

Il miglioramente della performance dovrebbe essere l'ultimo dei problemi, una cosa da fare proprio quando hai finito tutto il resto.

Yay!

pasquale7bellezze

#464 19-08-15 18:34

---

panzone

Metodologie di questo tipo in ogni caso le apprendi più sul campo che su libri. Io mi concentrerei sul migliorare le tue skill da sviluppatore (che non include solo studiare un po' di linguaggi. Imparare ad usare un SCM come git, imparare almeno i pattern più banali, imparare a scrivere codice ordinato son sicuramente più utili che leggerti 600 pagine su metodologie agili.

Sì git è in programma infatti.
Assolutamente ho proprio bisogno di quei concetti. Di solito nei corsi universitari come si apprendono le basi? Ci sono corsi specifici o sono in parte nei vari Programmazione I, II ecc.?
Allora quindi affianco il libro sui patterns e piuttosto mi informo online su roba impegnativa in scrum e agile. Grazie.

Affa

#465 19-08-15 18:39

---

Git si direi che è essenziale, personalmente lo inserirei proprio come corso universitario.

Yay!