PyCharm Dedicated Python IDE

Olá, daqui é o Alex do DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episódio 1 de 5. Configurar manualmente um ambiente Python complexo do zero leva muitas vezes a uma confusão de broken dependencies. Quando terminas de configurar o teu language server, linter e path variables, já passaste horas apenas a preparar-te para escrever código. O poder de uma IDE dedicada: o project setup resolve isto, dando-te um workspace unificado desde o primeiro clique. Antes de avançar, preciso de deixar claro que esta série não é patrocinada. Qualquer developer deve usar um editor com o qual se sinta produtivo. Mas há uma razão específica pela qual escolhi o PyCharm para desenvolvimento intensivo em Python. Editores de uso geral exigem que construas o teu próprio ambiente a partir de vários plugins. Uma IDE dedicada à linguagem oferece uma integração profunda e out-of-the-box, que entende a sintaxe de Python, o package management e a estrutura do projeto imediatamente. Quando estás a fazer o setup de um novo projeto Python, a tua primeira prioridade é o isolamento. Se instalares dependências diretamente na instalação de Python do teu sistema, vais acabar por poluir os teus packages globais e causar conflitos de versão entre diferentes aplicações. Para evitar isto, precisas de um virtual environment. No PyCharm, começas por criar um novo projeto Python puro. Dás um nome ao projeto e um directory path. Esta é a parte que interessa. Em vez de ires ao terminal para criar e ativar um ambiente manualmente, o PyCharm faz um prompt para configurares um interpretador Python logo na janela de novo projeto. Selecionas a opção para criar um novo virtual environment, apontas para a instalação base de Python na tua máquina, e a IDE trata do resto. Ela constrói o ambiente isolado e faz o bind automático ao teu novo workspace. Sempre que abrires este projeto, as dependências corretas já estão ativas. Assim que criares o projeto, vais notar uma pasta oculta chamada dot idea na raiz do teu workspace. As pessoas muitas vezes confundem o que pertence a esta diretoria com as global settings do próprio editor. As global settings da IDE controlam coisas como o teu tema visual ou atalhos de teclado personalizados em todo o teu trabalho. A diretoria dot idea é completamente diferente. Ela isola rigorosamente as project-level settings. Ela memoriza qual o virtual environment que este projeto específico usa, mapeia as tuas project roots, e guarda os code style overrides específicos para esta codebase. Como estas configurações definem como o projeto opera, a diretoria dot idea deve geralmente ser committed para version control. Isto garante que, quando um colega fizer clone do teu repositório, o editor dele reconheça imediatamente a estrutura do projeto sem configuração manual. Se gostas destes episódios e queres apoiar o programa, podes procurar por DevStoriesEU no Patreon. O valor final de uma IDE dedicada durante o setup é que ela absorve a tediosa carga cognitiva do environment management para que possas passar o teu tempo realmente a escrever business logic. Obrigado por ouvires, happy coding a todos!

Olá, daqui é o Alex do DEV STORIES DOT EU. PyCharm Dedicated Python IDE, episódio 2 de 5. A maioria dos developers ainda vai ao terminal para correr os seus testes e gerar reports de coverage. Nunca se apercebem que o seu IDE tem uma ação built-in, à distância de um clique, para destacar visualmente exatamente quais as linhas de código que ficaram por testar. Hoje vamos olhar para Hidden Gems: Run Configurations e Code Insight. O PyCharm não lê apenas o teu código como plain text. Ele faz o parse da tua lógica estrutural face às mais recentes Python enhancement proposals, conhecidas como PEPs. Se estiveres a usar o structural pattern matching introduzido na PEP 634, o editor valida ativamente os teus statements match e case. Ele garante que os teus patterns são exaustivos e alerta-te se um case for unreachable. Faz exatamente o mesmo para a nova syntax de type parameters da PEP 695. O IDE assinala instantaneamente mismatches de generic types de forma nativa, muito antes de sequer tentares correr o código. Quando o IDE deteta uma ineficiência ou uma potencial melhoria, oferece Intention Actions. Ao pressionares Alt e Enter, ou Option e Return num Mac, fazes trigger de uma lista de sugestões context-aware. Estas não são operações básicas de find-and-replace de texto. Como o PyCharm percebe a syntax tree subjacente do teu ficheiro Python, consegue reescrever com segurança um nested loop complexo numa dictionary comprehension limpa, sem quebrar a tua lógica. Ele atua sobre o node específico na estrutura do teu código. Depois de o teu código estar escrito e refinado, precisas de o correr. A maioria das pessoas clica no botão verde de play standard na toolbar principal e fica por aí. Mas o Run widget no topo da janela tem muito mais poder. Ao lado do botão de play está um menu More Actions, representado por três pontos. Abrir este menu revela formas completamente diferentes de lançar a tua aplicação. É aqui que encontras as opções para correr o teu código com o profiler ou executar a tua test suite com o coverage ativado. Muitos developers acham erradamente que têm de instalar manualmente uma tool de coverage, corrê-la a partir da command line e ler um bloco de output no terminal para ver os resultados dos testes. Não precisas de fazer isso. O PyCharm tem code coverage built-in diretamente no passo de execução. Quando selecionas Run with Coverage no menu More Actions, o IDE corre a test suite em background. Depois, faz o overlay dos resultados diretamente no teu editor. Ficas com marcadores verdes e vermelhos no gutter, mesmo ao lado dos números das tuas linhas. Verde significa que a linha foi testada, vermelho significa que foi completamente ignorada durante a execução. Para tornar este workflow seamless, usa o Run popup. Pressionar Alt Shift F10 em Windows e Linux, ou Control Option R no macOS, abre um menu flutuante com todas as project configurations. Aqui está o key insight. Não precisas de tocar no rato para mudar a forma como a tua app corre. Imagina que estás a fazer refactoring a uma função massiva e complexa. Fazes as tuas alterações estruturais usando uma Intention Action. Em vez de navegares para um tab do terminal, abres o Run popup, selecionas a tua test suite e corres instantaneamente com coverage. Em segundos, verificas se o teu refactoring funciona e se a tua nova lógica continua a ser totalmente testada. O verdadeiro valor de um IDE dedicado não é apenas escrever código mais rápido, mas sim encurtar o feedback loop entre alterar uma linha de código e saber exatamente como ela se comporta quando é executada. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. PyCharm, IDE dedicada para Python, episódio 3 de 5. Se o teu código está cheio de print statements só para veres o valor de uma variável, estás a desperdiçar horas de tempo de desenvolvimento. Está na hora de parar de adivinhar e começar a observar. Hoje, vamos falar sobre dominar o debugger: state e breakpoints. Imagina estares a tentar encontrar um bug num script de transformação de dados onde o valor de um dicionário passa misteriosamente a None. Se usares print statements, tens de escrever o print, correr o script, ler a consola, perceber que fizeste print da coisa errada, e começar tudo de novo. O debugger substitui este loop por completo. Permite-te pausar a execução do teu programa, inspecionar a memory heap, verificar os valores das variáveis e examinar os states das threads sem nunca modificares o teu source code. Para começar, defines um line breakpoint. Fazes isto clicando na margem esquerda do teu editor, ao lado do número da linha onde suspeitas que o problema começa. Aparece um ponto vermelho. A seguir, inicias o teu script em debug mode clicando no ícone do bug em vez do botão de run normal. O teu programa executa normalmente até chegar ao teu breakpoint. A execução é suspensa imediatamente antes dessa linha de código marcada correr. Quando o programa é suspenso, a tool window de Debug abre automaticamente. Aqui está o ponto chave. O Variables pane dentro desta janela dá-te um mapa interativo e em tempo real do state da tua aplicação. Vais ver todas as variáveis atualmente em scope. Podes expandir o teu dicionário para veres todas as suas keys e values naquele exato microssegundo. Também tens acesso à tool Evaluate Expression. Isto permite-te correr código Python arbitrário a meio da execução. Se quiseres correr uma list comprehension rápida nos teus dados ou verificar uma condição complexa, escreves isso no evaluator. Ele processa usando o state atual da aplicação e devolve o resultado. Podes até usar esta tool para fazer overwrite ao valor de uma variável on the fly, testando um possível fix ali mesmo, sem reiniciares a debug session. Também podes olhar para o Frames pane, que representa a tua call stack. Mostra a sequência exata de function calls que levaram ao teu breakpoint atual. Selecionar um frame diferente permite-te inspecionar as variáveis locais das funções que chamaram o teu código atual. Uma vez em pausa, tens de avançar a execução linha a linha para isolar quando o valor do dicionário passa a None. A isto chama-se stepping. Os developers costumam confundir step over com step into. Step Over significa executar a linha atual e pausar na próxima linha do ficheiro atual. Se a linha atual contiver uma function call, o Step Over corre essa função inteira em background e deixa-te na próxima linha do teu ficheiro ativo. Usas isto quando confias que a função funciona corretamente. Step Into significa mergulhar dentro da function call. O debugger move a execução para a primeira linha dessa função recém-chamada, permitindo-te seguir a sua lógica interna linha a linha. Ao usares breakpoints e stepping, tu controlas o flow. Fazes pausa logo antes do erro suspeito, fazes step into para a função de transformação, e observas o Variables pane a atualizar. A linha exata que executa imediatamente antes do valor do dicionário passar a None é a origem do teu bug. O debugger não é apenas uma tool para encontrar crashes. É uma lente interativa que te dá autoridade absoluta sobre o flow do teu programa e o memory state. É tudo por este episódio. Obrigado por ouvires, e continua a desenvolver!

Olá, daqui fala o Alex da DEV STORIES DOT EU. PyCharm, a IDE dedicada de Python, episódio 4 de 5. O código assíncrono torna as tuas aplicações incrivelmente rápidas, até ao momento em que um deadlock silencioso congela tudo e não deixa absolutamente nenhum error trace. Descobrir exatamente qual coroutine está bloqueada é notoriamente difícil. A solução no PyCharm é o Visualizing Async Code: o Concurrency Diagram. O código assíncrono é difícil de fazer debug porque um único event loop alterna constantemente entre tasks. Se construíres um web scraper assíncrono e, de repente, ele demorar dez minutos a correr em vez de dez segundos, o logging standard é praticamente inútil. Os print statements apenas geram uma parede caótica de texto intercalado. Sabes que uma task está à espera, mas não sabes qual nem porquê. Podes pensar que precisas de um CPU profiler standard aqui. Mas não precisas. Um CPU profiler standard diz-te qual a função que consumiu mais poder de processamento. A funcionalidade de Concurrency Visualization é diferente. É uma ferramenta especializada, desenhada explicitamente para fazer track aos estados das threads e aos event loops do asyncio ao longo do tempo. Mostra-te quando o teu código não está a fazer absolutamente nada. Acedes a esta funcionalidade através do widget de Run no topo da tua IDE. Abre o menu More Actions da tua run configuration, e escolhe a opção para fazer profile com a Concurrency Visualization. O PyCharm executa o teu código e depois gera um diagrama detalhado numa tool window dedicada. Dentro desta janela, seleciona a tab Asyncio graph. É aqui que a visualização propriamente dita acontece. A interface mostra uma timeline. Cada track horizontal representa um event loop ou uma thread. Ao longo destas tracks, o PyCharm desenha blocos que representam as tuas coroutines. O comprimento de um bloco mostra durante quanto tempo a coroutine existiu. É aqui que a coisa fica interessante. Cada bloco na timeline é identificado por cores com base no seu estado exato naquele milissegundo específico. Uma cor indica que a coroutine está a correr ativamente e a usar o CPU. Outra cor mostra quando está à espera, talvez por uma resposta da rede ou pela leitura de um ficheiro. Uma cor diferente destaca quando uma thread está completamente bloqueada. Aplica isto ao cenário do web scraper bloqueado. Em vez de tentares adivinhar porque é que o scraper está preso, corres a Concurrency Visualization. Olhas para o Asyncio graph e vês dez coroutines lançadas para fazer fetch de páginas web. Nove delas aparecem como um bloco sólido com a cor de espera. Podes clicar nesses blocos para ver exatamente que função representam. Percebes instantaneamente que estão todas paradas, à espera de um único network lock que uma coroutine anterior não conseguiu fazer release. Ver estes estados em tempo real nativamente na IDE é uma enorme vantagem em relação ao debug manual. Isto muda a tua perspetiva, passando da leitura de linhas de código sequenciais para a visualização de relações temporais reais. Encontras deadlocks não a fazer trace de erros lógicos na tua cabeça, mas a identificar fisicamente as cores de bloqueio e os espaços vazios num gráfico visual. A principal lição a tirar é que os bugs assíncronos são geralmente problemas de timing e estado, e o concurrency diagram traduz esses problemas de timing invisíveis num mapa visual claro. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.

Olá, daqui é o Alex da DEV STORIES DOT EU. PyCharm, IDE dedicada para Python, episódio 5 de 5. Partilhar o ecrã é ótimo para apresentações, mas quando uma database migration complexa falha localmente, apontar para um video stream não ajuda. Ambos precisam de ter as mãos no teclado, a interagir diretamente com o environment que está a falhar. É exatamente isso que o swarm programming usando o JetBrains Code With Me resolve. O Code With Me é uma feature built-in para desenvolvimento colaborativo remoto. Transforma o teu IDE local num workspace partilhado para swarm programming, mentoring e collaborative debugging. Imagina um cenário em que um colega júnior está com dificuldades numa database migration que falha apenas no seu setup local específico. Em vez de lhe pedires para fazer push de código com erros, ou tentares guiá-lo por comandos de terminal numa chamada, ele pode iniciar uma sessão remota diretamente do seu IDE. O setup tem uma relação distinta entre host e guest. O host é a pessoa que está a partilhar o seu projeto. Tem de ter o PyCharm instalado e a correr. Há um equívoco comum de que qualquer pessoa que se junte à sessão também precisa da sua própria licença paga do PyCharm. Não precisa. Os guests simplesmente recebem um link de convite gerado pelo host. Quando clicas nesse link como guest, o teu browser faz automaticamente o download e abre o JetBrains Client. Esta é uma aplicação leve que tem o aspeto e funciona quase exatamente como um IDE PyCharm completo, mas não processa nada localmente. Todo o trabalho pesado, indexing e syntax checking acontecem na máquina do host. Tens a experiência completa de native coding sem precisares de ter o source code clonado para o teu disco rígido. Quando abres a tua máquina a outro developer, a segurança e os limites são importantes. O host tem controlo granular sobre o que os guests podem fazer. Tu configuras isto antes de gerar o link. Acesso Read-only significa que o guest pode olhar para os ficheiros e seguir o teu cursor, mas não pode alterar nada. A permissão Edit files permite-lhe escrever ao teu lado em tempo real. Full access entrega as chaves, permitindo que o guest execute código, corra testes e interaja diretamente com o teu terminal local. Podes alterar estas permissões on the fly durante a sessão. Aqui está o insight principal. Não estás apenas a partilhar ficheiros de texto; estás a partilhar o runtime environment. Se o developer júnior correr um web server local no port 8000 para testar a sua migration, o developer sénior remoto normalmente não consegue aceder a isso. O Code With Me inclui uma feature de port forwarding para resolver isto. O host especifica um port local para partilhar. O JetBrains Client faz então o bind desse mesmo port na máquina do guest. O developer sénior pode abrir o seu próprio web browser local, navegar para localhost no port 8000, e interagir com a aplicação a correr na máquina do host. O collaborative debugging funciona melhor quando eliminas a fricção de reproduzir um broken state. Com o Code With Me, fazes bypass ao environment setup completamente e resolvem o problema real juntos, exatamente onde ele vive. Isto conclui a nossa série. Encorajo-te a ler a documentação oficial da JetBrains, a experimentar estas tools hands-on, ou a visitar devstories dot eu para sugerir tópicos para futuras séries. Obrigado por passares uns minutos comigo. Até à próxima, fica bem.