PyCharm Dedicated Python IDE

Ciao, sono Alex di DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episodio 1 di 5. Configurare manualmente da zero un environment Python complesso spesso porta a un groviglio di dipendenze rotte. Tra la configurazione del language server, del linter e delle variabili di path, finisci per passare ore solo a prepararti a scrivere codice. La potenza di un IDE dedicato: il Project Setup risolve questo problema offrendoti un workspace unificato fin dal primo clic. Prima di proseguire, ci tengo a precisare che questa serie non è sponsorizzata. Ogni sviluppatore dovrebbe usare un editor con cui si senta produttivo. Ma c'è un motivo ben preciso per cui ho scelto PyCharm per lo sviluppo intensivo in Python. Gli editor generici ti richiedono di costruire il tuo environment usando vari plugin. Un IDE dedicato a un singolo linguaggio offre una profonda integrazione out-of-the-box, che comprende immediatamente la sintassi Python, il package management e la struttura del progetto. Quando configuri un nuovo progetto Python, la tua priorità assoluta è l'isolamento. Se installi le dipendenze direttamente nell'installazione di sistema di Python, finirai per inquinare i pacchetti globali e causare conflitti di versione tra le diverse applicazioni. Per evitarlo, hai bisogno di un virtual environment. In PyCharm, inizi creando un nuovo progetto pure Python. Fornisci un nome per il progetto e un path per la directory. Questa è la parte che conta. Invece di passare al terminal per creare e attivare manualmente un environment, PyCharm ti chiede di configurare un interpreter Python direttamente nella finestra del nuovo progetto. Selezioni l'opzione per creare un nuovo virtual environment, lo punti all'installazione base di Python sulla tua macchina, e l'IDE gestisce il resto. Crea l'environment isolato e lo collega automaticamente al tuo nuovo workspace. Ogni volta che apri questo progetto, le dipendenze corrette sono già attive. Una volta creato il progetto, noterai una cartella nascosta chiamata dot idea nella root del tuo workspace. Spesso le persone confondono ciò che appartiene a questa directory con i setting globali dell'editor stesso. I setting globali dell'IDE governano cose come il tuo tema visivo o le scorciatoie da tastiera personalizzate per tutto il tuo lavoro. La directory dot idea è completamente diversa. Isola rigorosamente i setting a livello di progetto. Ricorda quale virtual environment usa questo specifico progetto, mappa le root del tuo progetto e memorizza gli override dello stile del codice specifici per questa codebase. Poiché questi setting definiscono come opera il progetto, la directory dot idea dovrebbe generalmente essere committata nel version control. Questo assicura che quando un collega clona il tuo repository, il suo editor riconosca immediatamente la struttura del progetto senza configurazione manuale. Se apprezzi questi episodi e vuoi supportare lo show, puoi cercare DevStoriesEU su Patreon. Il valore fondamentale di un IDE dedicato durante il setup è che assorbe il noioso carico cognitivo dell'environment management, così puoi passare il tuo tempo a scrivere effettivamente business logic. Grazie per l'ascolto, e buon coding a tutti!

Ciao, sono Alex di DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episodio 2 di 5. La maggior parte degli sviluppatori usa ancora il terminale per eseguire i test e generare i report di coverage. Non si rendono conto che il loro IDE ha un'azione single-click integrata per evidenziare visivamente le righe di codice che hanno appena saltato. Oggi guardiamo alcune gemme nascoste: le Run Configuration e il Code Insight. PyCharm non si limita a leggere il tuo codice come plain text. Fa il parsing della tua logica strutturale confrontandola con le ultime Python Enhancement Proposal, note come PEP. Se usi lo structural pattern matching introdotto nella PEP 634, l'editor valida attivamente i tuoi statement match e case. Si assicura che i tuoi pattern siano esaustivi e ti avvisa se un case è unreachable. Fa esattamente la stessa cosa per la nuova sintassi dei type parameter della PEP 695. L'IDE ti segnala istantaneamente i mismatch dei generic type in modo nativo, molto prima che tu provi a fare una run del codice. Quando l'IDE nota un'inefficienza o un potenziale miglioramento, ti offre le Intention Action. Premendo Alt e Invio, o Option e Return su Mac, attivi una lista di suggerimenti context-aware. Non si tratta di semplici operazioni di find-and-replace sul testo. Dato che PyCharm capisce il syntax tree sottostante del tuo file Python, può riscrivere in modo sicuro un nested loop complesso in una dictionary comprehension pulita, senza rompere la tua logica. Punta al node specifico nella struttura del tuo codice. Una volta che hai scritto e rifinito il tuo codice, devi eseguirlo. La maggior parte delle persone clicca sul classico tasto play verde nella toolbar principale e smette di esplorare lì. Ma il widget Run in cima alla finestra nasconde molto più potere. Di fianco al tasto play c'è un menu More Actions, rappresentato da tre puntini. Aprendo questo menu scopri modi completamente diversi per lanciare la tua applicazione. È qui che trovi le opzioni per fare una run del tuo codice con il profiler, o per eseguire la tua test suite con il coverage abilitato. Molti sviluppatori credono per errore di dover installare manualmente un tool di coverage, lanciarlo da riga di comando e leggere un blocco di output sul terminale per vedere i risultati dei loro test. Non hai bisogno di farlo. PyCharm ha il code coverage integrato direttamente nello step di esecuzione. Quando selezioni Run with Coverage dal menu More Actions, l'IDE esegue la test suite in background. Poi sovrappone i risultati direttamente all'interno del tuo editor. Ottieni dei marker verdi e rossi nel gutter, proprio di fianco ai numeri di riga. Verde significa che la riga è stata testata, rosso significa che è stata completamente saltata durante l'esecuzione. Per rendere questo workflow fluido, usa il popup Run. Premendo Alt Shift F10 su Windows e Linux, o Control Option R su macOS, fai apparire un menu fluttuante con tutte le configurazioni del tuo progetto. Ecco l'insight chiave. Non devi toccare il mouse per cambiare il modo in cui gira la tua app. Mettiamo che tu stia facendo il refactoring di una funzione enorme e complessa. Fai le tue modifiche strutturali usando un'Intention Action. Invece di spostarti su una tab del terminale, apri il popup Run, selezioni la tua test suite e la lanci all'istante con il coverage. In pochi secondi, verifichi che il tuo refactoring funziona e che la tua nuova logica è ancora completamente testata. Il vero valore di un IDE dedicato non è solo scrivere codice più velocemente, ma stringere il feedback loop tra il modificare una riga di codice e il sapere esattamente come si comporta quando viene eseguita. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episodio 3 di 5. Se il tuo codice è pieno di print statement solo per vedere quanto vale una variabile, stai sprecando ore di sviluppo. È ora di smettere di tirare a indovinare e iniziare a osservare. Oggi parliamo di come padroneggiare il debugger: State e Breakpoint. Pensa di dover scovare un bug in uno script di data transformation dove il valore di un dictionary diventa misteriosamente None. Se usi i print statement, devi scrivere il print, eseguire lo script, leggere la console, accorgerti di aver stampato la cosa sbagliata e ricominciare da capo. Il debugger sostituisce completamente questo loop. Ti permette di mettere in pausa l'esecuzione del tuo programma, ispezionare il memory heap, controllare i valori delle variabili ed esaminare i thread state senza mai modificare il tuo source code. Per iniziare, imposti un line breakpoint. Lo fai cliccando nel left gutter del tuo editor, di fianco al numero di riga dove sospetti che inizi il problema. Appare un punto rosso. Dopodiché, lanci il tuo script in debug mode cliccando sull'icona del bug invece che sul classico tasto run. Il tuo programma viene eseguito normalmente finché non raggiunge il tuo breakpoint. L'esecuzione si sospende immediatamente prima che quella riga di codice marcata venga eseguita. Quando il programma si sospende, la tool window di Debug si apre automaticamente. Ed ecco la cosa fondamentale. Il pane Variables all'interno di questa finestra ti dà una mappa live e interattiva del tuo application state. Vedrai ogni variabile attualmente in scope. Puoi espandere il tuo dictionary per vedere tutte le sue chiavi e i suoi valori in quell'esatto microsecondo. Hai anche accesso al tool Evaluate Expression. Questo ti permette di eseguire codice Python arbitrario a metà esecuzione. Se vuoi lanciare una rapida list comprehension sui tuoi dati o controllare una condizione complessa, la digiti nell'evaluator. L'evaluator la processa usando l'application state corrente e ti restituisce il risultato. Puoi persino usare questo tool per sovrascrivere il valore di una variabile al volo, testando un potenziale fix direttamente lì senza riavviare la debug session. Puoi anche guardare il pane Frames, che rappresenta il tuo call stack. Mostra l'esatta sequenza di function call che hanno portato al tuo breakpoint corrente. Selezionando un frame diverso puoi ispezionare le variabili locali delle funzioni che hanno chiamato il tuo codice corrente. Una volta in pausa, devi far avanzare l'esecuzione riga per riga per isolare il momento in cui il valore del dictionary diventa None. Questo processo si chiama stepping. I developer spesso confondono lo Step Over con lo Step Into. Step Over significa eseguire la riga corrente e mettersi in pausa alla riga successiva nel file corrente. Se la riga corrente contiene una function call, lo Step Over esegue quell'intera funzione in background e ti porta alla riga successiva nel tuo file attivo. Lo usi quando sei sicuro che la funzione lavori correttamente. Step Into significa entrare all'interno della function call. Il debugger sposta l'esecuzione alla prima riga di quella funzione appena chiamata, permettendoti di tracciare la sua logica interna riga per riga. Usando i breakpoint e lo stepping, sei tu a controllare il flow. Metti in pausa appena prima del presunto errore, fai Step Into nella transformation function e guardi il pane Variables aggiornarsi. La riga esatta che viene eseguita un attimo prima che il valore del dictionary diventi None è la fonte del tuo bug. Il debugger non è solo un tool per trovare i crash. È una lente interattiva che ti dà autorità assoluta sul flow del tuo programma e sul memory state. Questo è tutto per questo episodio. Grazie per aver ascoltato, e keep building!

Ciao, sono Alex di DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episodio 4 di 5. Il codice asincrono rende le tue applicazioni incredibilmente veloci, fino a quando un deadlock silenzioso non blocca tutto senza lasciare assolutamente alcuna traccia di errore. Scoprire esattamente quale coroutine è bloccata è notoriamente difficile. La soluzione in PyCharm è la visualizzazione del codice async: il Concurrency Diagram. Il codice asincrono è difficile da debuggare perché un singolo event loop passa costantemente da un task all'altro. Se crei un web scraper async e all'improvviso ci mette dieci minuti a girare invece di dieci secondi, il logging standard è praticamente inutile. I print statement producono solo un caotico muro di testo intrecciato. Sai che un task è in attesa, ma non sai quale o perché. Potresti pensare di aver bisogno di un CPU profiler standard in questo caso. Ma non è così. Un CPU profiler standard ti dice quale funzione ha consumato più potenza di calcolo. La feature di Concurrency Visualization è diversa. È un tool specializzato, progettato esplicitamente per tracciare gli stati dei thread e gli event loop di asyncio nel tempo. Ti mostra quando il tuo codice non sta facendo assolutamente nulla. Accedi a questa feature tramite il Run widget nella parte superiore del tuo IDE. Apri il menu More Actions per la tua run configuration e scegli l'opzione per fare profiling con la Concurrency Visualization. PyCharm esegue il tuo codice e poi genera un diagramma dettagliato in una tool window dedicata. All'interno di questa finestra, seleziona la tab Asyncio graph. È qui che avviene la visualizzazione vera e propria. L'interfaccia mostra una timeline. Ogni traccia orizzontale rappresenta un event loop o un thread. Lungo queste tracce, PyCharm disegna dei blocchi che rappresentano le tue coroutine. La lunghezza di un blocco mostra quanto è durata la coroutine. Ed è qui che la cosa si fa interessante. Ogni blocco sulla timeline è codificato a colori in base al suo stato preciso in quel determinato millisecondo. Un colore indica che la coroutine è attivamente in esecuzione e sta usando la CPU. Un altro colore mostra quando è in attesa, magari di una network response o di un file read. Un colore diverso evidenzia quando un thread è completamente bloccato. Applica questo concetto allo scenario del web scraper bloccato. Invece di tirare a indovinare sul perché lo scraper sia bloccato, esegui la Concurrency Visualization. Guardi l'Asyncio graph e vedi dieci coroutine lanciate per fare il fetch di pagine web. Nove di queste appaiono come un blocco solido di un colore di attesa. Puoi cliccare su quei blocchi per vedere esattamente quale funzione rappresentano. Noti all'istante che sono tutte in stallo, in attesa di un singolo network lock che una coroutine precedente non ha rilasciato. Vedere questi stati in real-time nativamente nell'IDE è un enorme vantaggio rispetto al manual debugging. Sposta la tua prospettiva dalla lettura di righe di codice sequenziali alla visualizzazione di vere e proprie relazioni basate sul tempo. Trovi i deadlock non tracciando mentalmente gli errori logici, ma individuando fisicamente i colori bloccati e gli spazi vuoti su un grafico visivo. La cosa più importante da portarsi a casa è che i bug async sono solitamente problemi di timing e di stato, e il Concurrency Diagram traduce questi problemi di timing invisibili in una chiara mappa visiva. Grazie per aver trascorso qualche minuto con me. Alla prossima, stammi bene.

Ciao, sono Alex di DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episodio 5 di 5. Lo screen sharing va bene per le presentazioni, ma quando una complessa database migration fallisce in locale, indicare un video stream non aiuta. Entrambi avete bisogno di mettere le mani sulla tastiera, interagendo direttamente con il broken environment. Questo è esattamente ciò che risolve lo swarm programming usando JetBrains Code With Me. Code With Me è una feature integrata per lo sviluppo collaborativo da remoto. Trasforma il tuo IDE locale in un workspace condiviso per swarm programming, mentoring e collaborative debugging. Immagina uno scenario in cui un collega junior ha difficoltà con una database migration che fallisce solo sul setup specifico della sua macchina locale. Invece di fargli pushare codice rotto, o cercare di guidarlo con i comandi da terminale in call, può avviare una sessione remota direttamente dal suo IDE. Il setup prevede una relazione distinta tra host e guest. L'host è la persona che condivide il progetto. Deve avere PyCharm installato e in esecuzione. C'è un malinteso comune secondo cui chiunque si unisca alla sessione debba avere una propria licenza PyCharm a pagamento. Non è così. I guest ricevono semplicemente un link di invito generato dall'host. Quando clicchi su quel link come guest, il tuo browser scarica e apre automaticamente il JetBrains Client. È un'applicazione leggera che ha un aspetto e un comportamento quasi identici a un IDE PyCharm completo, ma non processa nulla in locale. Tutto il lavoro pesante, l'indexing e il syntax checking avvengono sulla macchina host. Ottieni l'esperienza di coding nativa completa senza bisogno di avere il codice sorgente clonato sul tuo hard drive. Quando apri la tua macchina a un altro developer, la sicurezza e i limiti sono fondamentali. L'host ha un controllo granulare su ciò che i guest possono fare. Lo configuri prima di generare il link. L'accesso read-only significa che il guest può guardare i file e seguire il tuo cursore, ma non può modificare nulla. Edit files gli permette di digitare insieme a te in real time. Il full access consegna le chiavi, permettendo al guest di eseguire codice, lanciare i test e interagire direttamente con il tuo terminale locale. Puoi cambiare questi permessi al volo durante la sessione. Ecco il punto chiave. Non stai solo condividendo file di testo; stai condividendo il runtime environment. Se il junior developer fa girare un web server locale sulla porta 8000 per testare la sua migration, il senior developer remoto normalmente non può accedervi. Code With Me include una feature di port forwarding per risolvere questo problema. L'host specifica una porta locale da condividere. Il JetBrains Client poi fa il bind di quella stessa porta sulla macchina guest. Il senior developer può aprire il proprio web browser locale, navigare su localhost porta 8000 e interagire con l'applicazione in esecuzione sulla macchina host. Il collaborative debugging funziona al meglio quando elimini l'attrito di riprodurre un broken state. Con Code With Me, bypassi completamente il setup dell'environment e risolvi il vero problema insieme, esattamente dove si trova. Questo conclude la nostra serie. Ti incoraggio a leggere la documentazione ufficiale di JetBrains, a provare questi tool hands-on, o a visitare devstories dot eu per suggerire argomenti per le future serie. Grazie per aver passato qualche minuto con me. Alla prossima, stammi bene.