Percorso di formazione per Foundation

Sto preparando un help, da pubblicare sul sito della documentazione, per guidare un nuovo programmatore nell’apprendimento di Foundation e lo voglio condividere con voi per vedere cosa ne pensate.
Sarà un articolo che indica quali video tutorial e articoli vanno letti e il tempo impiegato per fruirli o leggerli.

Qui di seguito un riassunto degli argomenti generali.
Vi chiedo un feedback per indicarmi se manca qualcosa.

  • Step 1 - Introduzione ed installazione
  • Step 2 - Conosce l’ambiente
  • Step 3 - I database
  • Step 4 - Modello a oggetti - (documenti)
  • Step 5 - Interfacce
  • Step 6 - Scrivere il codice (il Visual Code Editor)
  • Step 7 - Gestione della login
  • Step 8 - Installazione
  • Step 9 - I Report
  • Step 10 - I Report come interfacce
  • Step 11 - Applicazioni di tipo Mobile
  • Step 12 - Sincronizzazione
  • Step 13 - Team Works
  • Step 14 - Web API
  • Step 15 - Alberi
  • Step 16 - Grafici
  • Step 17 - Server session
  • Step 18 - Integrazione componenti javascript
  • Step 19 - Approfondimenti (Componenti e il loro utilizzo)
5 Mi Piace

Aggiungerei (forse):
.componentizzazione (prima di mobile)
.personalizzazione tramite cartella custom (prima di integrazione componenti js)

1 Mi Piace

@r.bianco grazie dei consigli; la componentizzazione effettivamente va messa prima di altri argomenti anche se nel Tutorial delle applicazioni web si accenna ai componenti.
Per quel che riguarda la personalizzazione tramite la cartella custom se ne parla sempre nel Tutorial applicazioni Web ma possiamo mettere un capito a parte utilizzando il webinar che abiamo fatto sulla personalizzazione.

Ecco la lista aggiornata:

  • Step 1 - Introduzione ed installazione
  • Step 2 - Conosce l’ambiente
  • Step 3 - I database
  • Step 4 - Modello a oggetti
  • Step 5 - Interfacce
  • Step 6 - Scrivere il codice
  • Step 7 - Gestione della login
  • Step 8 - Installazione in produzione
  • Step 9 - I Report
  • Step 10 - I Report come interfacce
  • Step 11 - Suddividere in componenti le applicazioni
  • Step 12 - Applicazioni di tipo Mobile
  • Step 13 - Sincronizzazione
  • Step 14 - Team Works, lavoro di gruppo e versionamento
  • Step 15 - Web API
  • Step 16 - Visualizzazioni ad albero
  • Step 17 - Grafici
  • Step 18 - Personalizzazione tramite directory custom
  • Step 19 - Reflection ed eventi globali
  • Step 20 - Server session
  • Step 21 - Integrazione componenti javascript

Dato che si parla di formazione in autonomia di un utente alle prime armi, mi viene solo un dubbio terminologico: la tutti i termini che stiamo usando sono coerenti con quello che si aspetta l’utente?

Ad esempio: “componente” vuol dire quello che intentiamo oppure l’utente non ha questo vocabolo nel suo dizionario da informatico e non capisce. È importante che le parole facciano risuonare qualcosa all’utente (soprattutto all’inizio). Step 11 - Suddividere in componenti le applicazioni potrebbe diventare Step 11 - Creare una libreria applicativa con i Componenti. Significa la stessa cosa ma l’utente capisce meglio.

È solo un dubbio, eh, ma volevo condividerlo.
Le parole che mi lasciano più dubbi rispetto al mondo già noto ai programmatori sono: report (senza dire stampa almeno una volta), componenti, server session. Report è quella più comune ad altri linguaggi, l’unico dubbio è che il programmatore alle prime armi che approccia IDF non abbia ancora usato un report :sweat_smile:.

Voi che ne dite? È sensato cercare di lavorare sui termini o questa mia preoccupazione è superflua?

4 Mi Piace

@giuseppe.lanzi mi pare sensato quello che dici soprattutto per chi arriverà su questa pagina della documentazione e non sa nulla di Instant Developer Foundation.
Mi aspetto che se è un programmatore molto junior e non sappia cosa sia un report butti un occhio su Google o vista la tendenza attuale su TikTok.

Comunque grazie dei consigli.

Nuovo aggiornamento:

  • Step 1 - Introduzione ed installazione
  • Step 2 - Conosce l’ambiente
  • Step 3 - I database
  • Step 4 - Modello a oggetti
  • Step 5 - Interfacce per applicazioni web
  • Step 6 - Scrivere il codice
  • Step 7 - Gestione della login
  • Step 8 - Installazione in produzione delle applicazioni web
  • Step 9 - Creare stampe con i Report
  • Step 10 - Creare interfacce grafiche con i Report
  • Step 11 - Creare una libreria applicativa con i Componenti
  • Step 12 - Applicazioni di tipo Mobile
  • Step 13 - Sincronizzazione del database in applicazioni di tipo Mobile
  • Step 14 - Team Works, lavoro di gruppo e versionamento
  • Step 15 - Web API
  • Step 16 - Visualizzazioni ad albero
  • Step 17 - Grafici
  • Step 18 - Personalizzazione tramite directory custom
  • Step 19 - Reflection ed eventi globali
  • Step 20 - Elaborazioni batch con le Server session
  • Step 21 - Integrazione di componenti javascript
2 Mi Piace

Io suggerisco di aggiungere questi punti:

  • tecniche avanzate per la personalizzazione del css
  • utilizzo del debug

il primo per mostrare come si fa a scrivere bene custom.css (è già forse trattato allo Step 18) ma mi piacerebbe vedere una sezione che mostra anche l’utilizzo degli strumenti di sviluppo del browser, senza entrare troppo nei dettagli, ma almeno un po’.

Il secondo un tour guidato del debug in particolare dare delle dritte su come lo si legge e lo si usa (trattare almeno: debug su file, i comandi SM/HM e SS)

Per il resto mi sembra una buona lista.

Ciao.

2 Mi Piace

Ottima idea, sarebbe molto utile!

@f.faleschini sulla questione personalizzazione abbiamo un webinar specifico (Personalizzazioni grafiche web app) e nel tutorial delle applicazioni web si parla del debug di trace.
In ogni caso facci una verifica se c’è tutto quel che serve.
Grazie Francesco.

Quoto il punto della personalizzazione di @f.faleschini principalmente nell’ottica del nuovo framework Fluid.
Ho discusso molto con i miei colleghi facendo ipotesi sulla pulizia o struttura de css di base.
Immagino sarà molto meglio strutturato e organizzato di quello di rd3 poiché è stato creato con una ottica completamente nuova e modera.
Sarebbe però interessante avere delle dritte su quali siano le classi di base, come sono state organizzate ed in generale tutte le info per poter partire con una modifica dei css senza dover fare reverse engineering dell’attuale.

su questo punto sarebbe bello condividere nella documentazione o in questa community personalizzazioni al css per risolvere problemi specifici (Ad esempio il menu collassabile visto durante la presentazione)

4 Mi Piace

Mi è venuto in mente un altro punto importante:

  • come funziona il supporto ProGamma

Come cliente neofita 5 anni fa non capivo davvero come funzionano le assistenze e in particolare se un’assistenza era “spesa” per indagare un bug di inde mi seccavo particolarmente, ora so che è così che funziona e in realtà faccio molto più volentieri assistenze ora che allora.

Non che Pro Gamma non distribuisse ai clienti un pdf con la spiegazione dei servizi di supporto, però uno ci si scontra quando è già cliente, non sarebbe male capirne di più, evidenziando i vantaggi, in fase di formazione iniziale.

Ciao!

4 Mi Piace

@martino.vedana mi sembra un’ottima idea quella di un help specifico per la personalizzazione con Fluid e una serie di linee guida per il passaggio delle stesse da RD3 a Fluid.

@f.faleschini direi che spiegare bene il valore del supporto help desk di Pro Gamma è una cosa da fare che aggiunge valore alla descrizione del frame work.

Devo dire che questa Community arricchisce tutti e i vostri consigli sono veramente preziosi :grinning:

CIao @paolo.giannelli, mi è venuto in mente un altro argomento da trattare, o almeno da citare, perché è un plus di Foundation che io ho scoperto usandolo, ma non lo conoscevo quando ho acquistato la prima licenza o ho fatto il corso introduttivo con Pietro Cavallini: l’usp del profiler incluso nel debug. Ho già suggerito di parlare di debug, ma non di profiling inteso come “capire perché qualcosa è lento”. Ogni applicazione basata sul DB si scontra con problemi di performance quando i record di una tabella da 25 che sono in fase di sviluppo diventano 100000 in produzione.

Avere l’accesso ai tempi di esecuzione dei singoli metodi, nonché il tempo progressivo su ogni riga di codice è di estremo aiuto quando si indagano problemi di performance, in altri ambienti, mi viene in mente il mondo Delphi da cui provengo, per fare profiling in modo facile si devono acquistare costosissimi software, oppure ricorrere a tool bizzarri e scomodi, alla fine arrivi al risultato,ma è una pena e uno deve dire “ora mi metto a misurare e smetto di scrivere codice”, invece con Foundation la misurazione è a distanza di un click.

Far capire come si usano Time / Time Total / Call count e la facilità di approccio a questi dati è a mio avviso fondamentale: di per sè questa feature vale la scelta di Foundation, perché la volta che hai un vero problema di performance ti permette di venirne fuori da solo e capire cosa succede.

Nella mia esperienza pre-Foundation, per mancanza di strumenti adeguati di profiling ho dovuto ricorrere in alcuni casi ad accrocchi improbabili per racimolare qualche millisecondo di runtime qua e là, con Foundation tutto è sotto controllo.

Diciamo che sono informazioni che avrei apprezzato 5 anni fa e apprenderle in un percorso introduttivo mi pare buono.

Ciao!

2 Mi Piace

Sono un po’ in ritardo ,non so se è gia incluso negli step ma troverei abbastanza utile anche un piccolo approfondimento dei vari componenti “ID” ,tipo “IDform” ,“IDmap”,ecc. Inizialmente mi confondondevano un attimo quindi è possibile che qualcuno con poca esperienza potrebbe trovarlo comodo.

1 Mi Piace

@petrini.alessio grazie del tuo contributo vedo se è già presente o meno.

Sono interessantissimi i vostri suggerimenti, leggendoli mi saltano all’occhio come delle categorie di argomenti. Quello che aveva in mente @paolo.giannelli era di avere una parte della doc per chi approccia Instant Developer (d’ora in poi “ID” altrimenti lo scrivo 50 volte), per il nuovo sviluppatore, e quindi gli argomenti che ha proposto nella prima lista sono tutti di carattere generale.

Negli suggerimenti di @f.faleschini trovo due categorie: webinar (tecniche per la personalizzazione del css, che non è propriamente uso di ID e che non ha una strada giusta e una no) e approfondimenti (utilizzo del debug). Non ché Supporto (come funziona il supporto Pro Gamma) in cui mi sento chiamato direttamente in causa.

È tanto tempo che voglio pubblicare una specie di carta dei servizi in cui spiegare come funzioniamo. Sono ormai 2-3 anni che al termine del percorso di tutoraggio faccio personalmente un’introduzione al supporto, ma mettere un’informazione nella documentazione è sicuramente utile. Ci lavoro con Paolo senza dubbio.

Concordo con @martino.vedana sul fatto che sarebbe bello condividere nella community (più che nella doc) personalizzazioni CSS fatte, anche embrionalmente. Potrebbero nascere delle discussioni apposta per “che ne dite di quel che ho fatto?” o “vorrei fare questo, voi come lo fareste?”. La community è il posto perfetto per questo. Mi chiedo se il posto giusto sia la community o il forum, forse un po’ border line? Non saprei decidere.

Vorrei fare una precisazione: distinguo tra webinar e approfondimenti perché un conto è sapere come funziona qualcosa fino in fondo (approfondimento) e un altro paio di maniche è capire come applicarlo (webinar).

Per intenderci, prendiamo ad esempio la segnalazione di @f.faleschini su come funziona il debug e come risolvere una lentezza applicativa. È molto interessante. Ma per poter svolgere quel lavoro sono necessari due aspetti: la conoscenza del debug e la formazione/esperienza su come usarlo. Le due cose non possono andare insieme. I casi sono così tanti e variegati che non è possibile metterli in un articolo di approfondimento su “come funziona il debug”.

Io personalmente anni fa ho aiutato a risolvere una procedura che impiegava ore. Una delle cause era una tabella IMDB su cui veniva fatto spesso select into variables. Il problema era che la tabella aveva 100 K righe e quindi il numero di iterazioni totali sulla tabella era nell’ordine dei 1000 M. Abbiamo messo un IDMap e tutto si è risolto.

Anche le richieste di @petrini.alessio sono molto interessanti, perché quei componenti sono un po’ una scatola nera per molti sviluppatori.

Secondo voi ha senso procedere contemporaneamente in 3 direzioni diverse: documentazione per “come funziona”, webinar per “come si usa” e community/forum per “vediamo insieme come applicarlo”?

Ha senso?

2 Mi Piace

Ultimamente mi sono trovato spesso a consultare gli strumenti di formazione che Microsoft ha realizzato per .NET. Li ho trovati ben strutturati e molto utili.

Hanno due tipi di articoli: la documentazione classica (esempio) e lo spiegone per le scimmie con gli esempi (esempio). In quanto io scimmia li utilizzo entrambi, in base al mio livello di preparazione/esperienza sull’argomento.

Il vantaggio di averli tutti su testo, rispetto ai webinar video, è che sono più facili da manutenere/aggiornare nel tempo (per ovvi motivi) e allo stesso tempo li trovo più facilmente consultabili perché posso andare a colpo d’occhio sul punto che mi interessa senza dover guardare 10 minuti di video senza sapere il punto esatto che mi interessa.

I video corsi/webinar li ho trovati utili come primo approccio sull’argomento per capire in che mondo si è catapultati e per avare un infarinatura generale (esempio).

Poi per i casi specifici d’uso e gli approfondimenti più svariati c’è sempre stack overflow.

1 Mi Piace

Molto interessante. La reference tecnica e lo spiegone. Mi spiace l’idea di spiegone, rientra molto nelle mie corde. In effetti si potrebbero fare articoli così. @paolo.giannelli pensiamoci.

P.S.
spiegone mi ricorda tanto la categoria di giochi cinghiale, e quindi a pelle mi piace tantissimo (rientrando sia nella categoria di quelli che fanno gli spiegoni sia nella categoria dei nerd).

2 Mi Piace