Idee sparse

[Cadienvan]

Apro questa discussione per raccogliere le idee più disparate e varie, mantenendo un canale aperto ora che non è (giustamente) più possibile aprire discussioni se non si è perlomeno in ruolo di triage.

[rrhinox]

ciao @Cadienvan, intanto complimenti per l'idea ed il progetto, grande!
Non sono un dev, ma ci lavoro da vicino e mi piacerebbe contribuire al progetto su alcuni temi che vivo ed ho vissuto. Spero di non essere arrivato troppo tardi e che possano essere utili, in qualche modo, al libro :)

• Logging - standardizzare i log, log collection, log retention, dare il giusto "peso" ai log (logLevel) e cosa scriverci dentro per renderli davvero utili e funzionali all'observability e alle necessità dei team e un pò per tutti
  https://www.redhat.com/en/topics/devops/what-is-observability;

• Monitoring e Telemetry - tools, use cases e best practices (si collega al logging)

• quale GitFlow adottare in un team - mi piacerebbe mettere giù delle linee guida per tipo di organizzazione del lavoro e grandezza del team in questione; cosa è meglio per chi e come applicarlo nei vari contesti e linguaggi/framework conscio che poi ognuno ha le sue esigenze specifiche.
  Una cosa del genere (vedi anche References in fondo all'articolo):
  https://blog.devgenius.io/gitops-part-1-basically-what-is-git-flow-and-gitops-is-it-can-apply-for-everywhere-af259ec1460c

• GitOps, CI/CD e IaC - come integrare build dei sorgenti sw, infrastruttura, testing e security in ottica di CI/CD tramite pipeline o automazione/scripting.

• Pratiche e principi DevOps nel ciclo di vita del SW - collaborazione, trasparenza, automazione etc..
  "The key premise behind DevOps is collaboration." - "The values of a DevOps culture include increased transparency, communication, and collaboration across teams.":
  https://www.atlassian.com/devops/what-is-devops

• Git & Secrets - come gestire al meglio i segreti nei repository

• Performance testing includes load test and stress test - io avevo usato jMeter però c'è comunque bisogno di collaborare coi dev (e non solo) per mettere in piedi dei test plan sensati;

Forse ho esagerato... vabbè in ogni caso su qualcosa posso contribuire, ditemi quello che devo fare e lo faccio XD
"hai la mia ascia"

[Cadienvan]

Ciao @rrhinox ,
grazie mille per le idee e per aver voluto contribuire!

Non è mai troppo tardi per entrare nel progetto, se vuoi proporti come ambassador ti aspettiamo nella discussione apposita: #5 !

In ogni caso, grazie enormemente!

[nicolaerario]

Idea sparsa:

Prendiamo in considerazione l'utilizzo delle GitHub Pages?
In modo da avere una versione del libro sempre disponibile online per tutti.

Se ci piace, consiglio di predisporre una cartella dedicata per le pagine del libro (normalmente la cartella docs) a cui far puntare le GH Pages e magari sfruttare il webhook dedicato per avvisare gli iscritti alla newsletter dell'uscita del nuovo capitolo.

Note

Forse sono andato troppo avanti con la fantasia, volevo solo esprimere le potenzialità della mia idea

[Cadienvan]

Mi piace ogni singola parola che hai detto.

Le potenzialità ci sono eccome!

[nicolaerario]

Oggi ho fatto una PR verso il nostro book e mi sento un po' colpevole: colpevole del fatto di averla titolata usando la lingua inglese.
Ammetto che è molto piacevole discutere, commentare, anche aggiungere i dettagli di una PR in italiano ma mi chiedo, in un ottica futura e, soprattutto, in un ottica di open source, non sarebbe opportuno mantenere la history in inglese?

Attendo le vostre considerazioni ma nel frattempo, @Cadienvan posso chiederti di attivare questa impostazione per il repo?

La nostra history sarà molto più leggibile.
Grazie

PS: a votazioni finite, se avrò la possibilità di avere accesso alla org, sarà un piacere per me aiutare anche nella configurazione

[nicolaerario]

Mi sono appena reso conto da solo che tutti i commit sono in realtà in inglese, ottimo! Quindi quello che ho scritto si trasporta nell'attivazione dell' impostazione che suggerisco con la conseguente attenzione di titolare le PR in inglese. Che ne pensiamo?

[Cadienvan]

Ciò che dici mi torna molto. Anche in ottica di apertura futura del progetto mi sta bene discuterne in italiano, ma finalizziamo le PR in inglese. Vediamo se qualcuno ha altre opinioni a riguardo ma.... "Per me è un sì!"

[Cadienvan]

P.S. l'impostazione è stata attivata, mi torna e ancora sì se volessi aiutare con la configurazione a votazioni concluse! Sarebbe un enorme piacere!

[mariomontella]

Ciao ragazzi, trovo il progetto molto interessante. Tuttavia, credo che potrebbe essere una buona idea inserire un capitolo in cui si parla di "Mobile Development".

[Cadienvan]

Ottima idea, grazie!

[Eomm]

I SOLDI

Leggo dall'indice che un dev imparerà:

• molte cose per fare bene il suo lavoro
• molte cose per fare carriera nel suo lavoro
• alcune cose per non morire male mentre fa il suo lavoro

ma manca un capitolo in cui cura brutalmente i suoi interessi.

Nel dettaglio, le domande più ricorrenti nei vari gruppi telegram sono i soldi.
Per fare una pesa: ad ogni domanda su come muoversi su un balanced tree, corrispondono 100 domande su contratti, RAL e tassazione.

Son qui a suggerire un capitolo sui soldi:

• come gestire la crescita salariare: e se non cresce in 3 anni che sono in un'azienda?
• cosa è una PEO e come lavorare per l'estero dall'italia
• il pericolo delle donazioni: la croce e delizia di ogni commercialista. Una donazione è esentasse o vi tocca pagare il 50% di imposte?
• avviare un vostro progettino con supporto a pagamento: in cosa incorrete?
• i contratti di telelavoro, cosa sono? Dev, siete veramente dei metalmeccanici?

Insomma, cose che i dev fanno tutti i giorni, ma non se ne curano bellamente finchè cominciano ad arrivare i primi soldi e non sanno che fare.

Questo capitolo andrebbe a dare i rudimenti su questi aspetti, che facilita la vita e riduce lo stress.

PS: le mie competenze su questo aspetto si possono riassumere in: "pagate un commercialista per farlo" ma sarebbe bello che ci fosse un commercialista OSS che spieghi queste cose per evitare, al solito, che ci freghino perchè (noi dev) non sappiamo contrattare a prescindere.

[JeyDi]

Bellissimo questo capitolo!!! è un buco nero perchè rischia di essere un libro a se stante, ma personalmente sarei super curioso di leggerlo :)
A questo punto aggiungerei anche: e se espatrio? Cosa succede e come devo fare?

[Cadienvan]

Bellissime idee @Eomm, quasi da candidarti come ambassador per dire la tua ahahah
Grazie anche a @JeyDi per l'aggiunta, ne parliamo nel primo meeting settimana prossima insieme alle altre proposte, molto molto interessante!

[blanquicet]

Mi piace molto questa proposta! Dobbiamo lasciare da parte questo tabù che non ci permette di parlare di soldi apertamente. Mi aggiungo a quest'iniziativa e sarei felice di contribuire (non solo a questo capitolo 😝).

[Cadienvan]

Grazie @blanquicet , le candidature sono ancora aperte fino a fine mese se vuoi candidarti come ambassador ed essere il frontman del capitolo, altrimenti ti basta andare qui (#103 ) e mettere un commento o un pollice su per confermare il tuo interesse!

[GuidoPenta]

Se volete posso coinvolgere una consulente del lavoro esperta di temi IT e tech, ne parliamo nel meeting (o al codemotion per chi ci sarà)

[halfpass25]

Ho riassunto tutte le idee proposte, solo i titoli, così a colpo d'occhio è più facile farsi idea di cos'altro si potrebbe aggiungere.
Se qualcuno volesse continuare ad utilizzare la lista numerata che ho creato, penso gli sia sufficiente copiarla da questo post ed incollarla in uno nuovo.
Meglio ancora: potremmo creare un thread specifico solo per le liste riassuntive, così da non dover cercare ed avere sempre la situazione aggiornata ;)
Vi parlo per ora da "uditore" perché l'iniziativa mi piace e a prescindere dal potervi partecipare attivamente, mi fa piacere contribuire, per quel che posso.
Qualcuno potrebbe chiedersi perché anche io che sono uno sviluppatore ho deciso di occuparmi di traduzioni invece che di best practices.
Il fatto è che ho trascorso quasi tutta la vita lavorativa su sistemi real-time dove il fattore chiave era il "tempo" e quindi, qualunque zozzonata, anche il codice più ignobile, andava bene a condizione che rosicchiasse millisecondi sui tempi di elaborazione.
E niente, posso mai presentarmi alla gente con consigli simili? :)
Vabbè, poi se mi viene qualche idea migliore, magari ve la propongo!
E adesso... riassunto delle idee proposte, dajie!

1. Logging - standardizzare i log, log collection, log retention,
2. Monitoring e Telemetry - tools, use cases e best practices (si collega al logging)
3. quale GitFlow adottare in un team
4. GitOps, CI/CD e IaC
5. Pratiche e principi DevOps nel ciclo di vita del SW
6. Git & Secrets
7. Performance testing includes load test and stress test
8. Prendiamo in considerazione l'utilizzo delle GitHub Pages?
9. In modo da avere una versione del libro sempre disponibile online per tutti.
10. non sarebbe opportuno mantenere la history in inglese?
11. "Mobile Development".
12. I SOLDI

[dinb79]

Scusate la domanda niubba ma, se io volessi iniziare a produrre contenuto, in che modo dovrei aggiungerlo e dove?
C’è già un indice condiviso e accettato, o lo si farà alla fine derivandolo dai contenuti?

[Cadienvan]

L'indice arriverà sicuramente più avanti, non saprei ancora dirti quando perché proprio mercoledì prossimo ci sarà la prima riunione tra Ambassador, di conseguenza da lì estrarremo tutti i main topic e stabiliremo un po' come lavorare!

[Cadienvan]

Il suggerimento al momento è quello di salvarti un doc di qualche tipo con tutti gli spunti per poi contribuire una volta che la macchina si sarà messa in moto!

[Livio74]

Ciao a tutt*

mi piacerebbe una certa organizzazione quindi lancio qualche domanda/spunto.
Ad esempio ogni segnalazione/discussione avrà un argomento a cui attaccarla in modo da renderle più ordinate.
Come possiamo gestirla al meglio per far si che i temi trattati nei vari post siano legati correttamente alle issue o alla pagina o ad altro?
Magari potrebbe essere utile un post dove raccogliere alcune info sull'organizzazione dei vari elementi come appunto i post , le issue , ecc.
Infatti mi è venuto spontaneo usare questo post per scrivere il mio post immaginandomi la regola implicita che se non so catalogare il post che sto scrivendo lo metto qui quindi si potrebbe ad esempio creare una discussione per categoria , cosa che in parte è già stata fatta.
Ho espresso il concetto in modo un po' fumoso ma l'obiettivo è quello espresso appunto nella prima frase cioè migliorare l'organizzazione.

Ciao e buona serata a tutti

[eppak]

Ciao @Livio74, mi sembra che tocchi aspetti differenti del progetto, cerco di darti una panoramica: per seguire meglio i vari elementi ci stiamo suddividendo in focus group dove andiamo a disciplinare quello che tu hai menzionato, li trovi qui: https://github.com/Il-Libro-Open-Source/governance/blob/main/WG.md In generale trovi questi argomenti nel repository Governance: https://github.com/Il-Libro-Open-Source/governance.

Come vedi da issue, discussioni e pull c'è molto fermento e stiamo piano piano toccando i vari argomenti per cui ti chiedo prima di tutto se ho almeno parzialmente risposto alla tua domanda e se vuoi aggiungere altri dettagli così da accogliere anche il tuo contributo.

Grazie!

[phaberest]

Ciao bella gente! 🙌🏻

Io parlerei di come "sopravvivere a una code review ed essere tutti amici", che in parole povere vorrebbe evidenziare quali possano essere le pratiche che chi sviluppa una feature può adottare per ottimizzare il testo descrittivo di una PR e organizzare il proprio codice e le proprie commit al fine di rendere più agevolata e snella la revisione che dovrà fare chi curerà la code review

[Cadienvan]

Ci sono argomenti relativi al lavoro in team, potrebbe starci bene!! Grazie !

[feuerbach81]

Da fruitore di diversi progetti open source in passato (ormai sono lontano dal mondo dei Dev), "sprecherei" un intero capitolo del libro intitolandolo "L'importanza dei commenti e della documentazione"

[Cadienvan]

@feuerbach81 grazie per aver contribuito con questa idea!

Sì, sicuramente, infatti la issue #97 è proprio per l'argomento Documentazione!

Se ti va di contribuire metti un pollice su lì dentro e magari comincia a proporre dei contenuti con un commento, che ne pensi?

Grazie ancora 🚀

[tonycaputome]

Potremmo inserire anche la creazione / manutenzione di un design system e quanto sia importante per un'azienda più tutte le difficolta di mantenerlo.

[Cadienvan]

Mi sembra un ottimo argomento! Non saprei bene se vederlo come tema a parte o se inserito in altri, forse per conto suo avrebbe senso, ma grazie Antonio, effettivamente è un tema interessante! Vediamo se qualcuno del team @Il-Libro-Open-Source/ambassadors vorrà prendersi carico di "dirigere" i lavori! Hai già una idea di temi che tratteresti, una sorta di table of contents?

[tonycaputome]

Una lista di argomenti potrebbe essere questa.

• Quando introdurlo e se introdurlo
• Definizione dei "tokens" che comporranno il DS
• Comportamento dei components come brand identity (sembra lo slider delle anteprime dei films tipo "Netflix")
• Come gestire il versionamento dei components.
• Manutenzione del repo e sua struttura (monorepo or not)
• Documentazione del DS (Storybook, Styleguidist)
• Strumenti di collaborazione (Figma, Zeplin, Invision)

Guidelines da Figma
https://www.designsystems.com/

[GiovanniRic]

Ciao,
questo libro sarà una cosa spettacolare.
Complimenti!

Un argomento che vorrei proporre è come vivere il nostro lavoro dopo i 45-50 anni. Ci sono ovviamente esperienze personali e sicuramente non sarà possibile trovare una risposta assoluta, ma affrontare il tema sarebbe interessante.

Gli argomenti potrebbero essere:

• Bisogna per forza diventare manager dopo i 45 anni? Quali sono i percorsi alternativi che permettono di essere sempre in prima linea sull'aspetto tecnico? E in questi percorsi, si scriverà ancora codice?
• È possibile essere competitivi sul mercato come lo sarebbe un 30 enne? Come si comportano le aziende sulla questione?
• Esempi reali (se possibile) di come molte volte l'esperienza faccia la differenza rispetto a conoscere bene le tecnologie all'ultimo grido.
• Quali obiettivi/consapevolezze/conoscenze bisogna raggiungere dopo quasi 20 anni di esperienza in questo campo? (Molto spesso gli anni di esperienza non valgono nulla se per tanti anni si fanno le stesse cose).

Non so se è un argomento valido, spero almeno di aver tanto qualche spunto interessante su temi simili.

[Cadienvan]

Ciao @GiovanniRic ,
mi sembrano dei punti molto interessanti ed effettivamente possono valere la pena.

Saresti interessato eventualmente a stendere una parte di questo contenuto?
Mi piacerebbe scrivere assieme questo argomento ma non voglio diventare il collo di bottiglia essendo responsabile di altri capitoli.

Fammi sapere e ti faccio da Ambassador per questo capitolo!

Hai un'idea per un nome? Eviterei l'anno specifico (45) perché ognuno ha la sua opinione riguardo all'età, andrei su qualcosa di più neutrale del tipo "Le fasi della vita del developer. Come affrontare l'età.", cosa ne pensi?

[GiovanniRic]

Ciao @Cadienvan!

Sono molto contento che trovi interessante il tema e ti ringrazio molto per la proposta di nominarmi Ambassador. La sindrome dell'impostore non mi farebbe accettare, tenendo conto che non ho esperienza di Open Source, ma voglio mettermi in gioco e soprattutto credo che questo progetto abbia tutte le potenzialità di diventare un ottimo manuale per tutti i devs. Accetto volentieri!
Ho dato già un'occhiata della pagina degli Ambassador.

Per il titolo, d'accordissimo non specificare l'età, che è molto relativo (come un po' tutto il tema).
Non inserirei la parola 'fasi' per non correre il rischio di ripetere dei concetti che potrebbero esserci nei capitoli dedicati, appunto, alle fasi di carriera ( junior/mid/senior). Questo capitolo credo sia più generico dove sarà più importante raggruppare varie considerazioni/esperienze di devs con diversi anni di esperienza per arrivare (forse) a delle conclusioni più o meno oggettive.

Ecco alcuni titoli:

• Come affrontare l'età nel mondo IT.
• I devs e l'età che avanza.
• I devs e le sfide del tempo.
  O qualcosa con un pizzico di ironia:
• Il tempo passa anche per i devs.

Cosa ne pensi?

Grazie ancora per avermi coinvolto!

[Cadienvan]

Ciao @GiovanniRic , perdonami sono stato poco chiaro ahah al momento le candidature ad Ambassador sono chiuse, ma potrei farti IO da ambassador di riferimento per il capitolo, in quanto per aprire un nuovo argomento è comunque necessario che almeno un ambassador se ne faccia carico, anche solo a livello di "guardrail" di sicurezza.

Mi piacciono i contenuti, probabilmente sarà un argomento piccolo perché oltre che delle considerazioni e degli spunti di riflessione dubito ci sia moltissimo, ma volentieri lo vorrei incluso nel libro, quindi se mi confermi il tuo interesse per stendere una prima bozza di questi contenuti e da lì iterare assieme creo la issue e ti do due dritte su come cominciare!

Aggiungerei una sola voce, che avevi citato e che non vorrei perdermi nella stesura: Posso continuare ad essere dev, oppure devo diventare manager?

Attendo conferma e partiamo ;)

[GiovanniRic]

Ciao @Cadienvan,
scusami tu che ho interpretato male ahah!

Per me possiamo partire, ti aiuto molto volentieri. 💪

[Cadienvan]

#157 @GiovanniRic quando vuoi forka il branch specifico e buttatici!
Dai un'occhiata al CONTRIBUTING.md prima di cominciare ;)

[FedericoSerini]

Ciao a tutti,
Mi congratulo per l'iniziativa e per la 'pubblicità' attorno ad essa.

Forse quello che sto scrivendo è stato già riportato da qualcuno

A ogni modo vorrei veder riportata una sezione tecnica interamente incentrata sul concetto di micro servizio.

A mio parere inserirei i seguenti concetti:

• Cos'è veramente un micro servizio (Ho visto troppi monoliti distribuiti e/o architetture SOA spacciati per tale)
• Il debito tecnico che porta adottare una architettura a micro servizi, sia in termini tecnici che organizzativi
• Adottare una metodologia di sviluppo atta a mascherare l'utilizzo di provider cloud
• Come migrare da una architettura monolitica a una a micro servizi
• Discutere il versionamento nel caso in cui un micro servizio comunichi tramite protocollo HTTPS
• Discutere l'adozione di più linguaggi all'interno del dominio di un micro servizio e cosa comporta in termini aziendali
• Gestire la retrocompatibilità in un ecosistema enterprise
• Discutere della granularità di un micro servizio
• Discutere dell'approccio DDD (Domain driven design)
• Sottolineare la differenza tra una programmazione sincrona da una asincrona/reattiva
• Discutere della messa in produzione di un micro servizio (Kubernetes, Helm, Keda ecc..)
• Testing di micro servizi (Ad esempio il contract testing)
• Monitoring, Tracing e altre componenti infrastrutturali

Di argomenti legati se ne possono trovare tanti come vedo già riportati in questo thread come il logging e i secret..

Spero di esser stato utile alla causa o quantomeno esser stato chiaro

[corradopetrelli]

Ciao, grazie mille!

Ti consiglio di proporre ognuno di questi argomenti sulla/e issue/s che più si adattano all'argomento, qui trovi tutti i capitoli finora proposti.

Secondo me la maggior parte si adatta al capitolo: #105
La parte del debito tecnico: #99
La parte riguardo il cloud: #140

Dal mio punto di vista gli argomenti da te proposti possono racchiusi su un capitolo già esistente, se in un futuro diventa estremamente grande nulla ci vieta di estrarre il tutto per creare un nuovo capitolo 😄 .

[Cadienvan]

Sono pienamente d'accordo con @corradopetrelli , ti aspetto nella #123 per ampliare quanto già scritto, credo possa valer la pena essendo una buzzword degli ultimi anni, approfondire il mondo microservizi. Ci vediamo là? ;)

[mcau92]

Ciao ragazzi,
Innanzitutto GRAZIE e complimenti per l'idea, la trovo super super utile!

Rileggendo i vari capitoli volevo consigliare di gestire come punto ad hoc la questione "soft skill", potrebbe rientrare nei vari punti dedicati alle varie seniority ma, a mio parere, è un punto veramente importante per poter essere un buon programmatore e per poter cresere in questo settore.
Ovviamente può andare di pari passo anche con la gestione della Leadership.

Spero di esservi stato utile ;)

[Cadienvan]

Ciao, grazie a te per il contributo!

Sì, è un tema che tratteremo in vari modi in vari capitoli, se ti va di unirti alla stesura dai un'occhiata alle issue sugli argomenti e proponi delle idee oppure contribuisci alle PR già aperte!

[Livio74]

Ciao a tutti,

nel file CONTRIBUTING.md volevo segnalare che se lavoro su Windows il comando npm run format:check (e anche write) non funziona, bisogna lanciarlo da riga di comando così:

npx prettier --check '**\*.md'

questo perché il comando è unix style , non so se in generale con npm si può lanciare lo stesso comando e se è windows fargli fare il comando unix like e se windows lanciare il mio

[Cadienvan]

Ciao Livio! Ti suggerirei di aprire una Issue piuttosto che scriverla qui! Nel frattempo taggo il @Il-Libro-Open-Source/tech-group che so ha dovuto affrontare la questione di recente.

[Livio74]

Fatto , la issue è la numero 174

[Livio74]

Ciao a tutti,

propongo una issue apposta per le domande e risposte (tipo FAQ)
io ad esempio ne avrei qualcuna.

Livio

[Cadienvan]

Ciao Livio! Ne stanno parlando i ragazzi del @Il-Libro-Open-Source/discussion-group proprio in questi giorni!

[Livio74]

Ciao a tutti,

una delle domande ad esempio è come vengono creati i branch , mi sembrava di aver visto un documento apposta ma non lo trovo

Livio

[Cadienvan]

Dobbiamo specificare meglio. In ogni caso ti rispondo che basta aprire una Issue :)

[Livio74]

Fatto , issue num 175

[Jean85]

Ciao, scrivo qui perché non mi sembra ci sia un template per issue giusto per questa cosa: notavo che dal libro pubblicato sulle GitHub Pages non c'è nessun link che riporti al repo... Non sarebbe il caso di aggiungercelo? 😄

[Cadienvan]

@Il-Libro-Open-Source/tech-group io sarei d'accordo, che ne pensate?

[corradopetrelli]

#209