PyCharm Dedicated Python IDE

Cześć, tu Alex z DEV STORIES DOT EU. PyCharm Dedicated Python IDE, odcinek 1 z 5. Ręczna konfiguracja złożonego środowiska w Pythonie od podstaw często prowadzi do plątaniny zepsutych zależności. Zanim skonfigurujesz swój language server, linter i zmienne PATH, tracisz godziny na samym przygotowaniu do pisania kodu. Potęga dedykowanego IDE: Project Setup rozwiązuje ten problem, dając ci ujednolicony workspace już od pierwszego kliknięcia. Zanim przejdę dalej, muszę wyraźnie zaznaczyć, że ta seria nie jest sponsorowana. Każdy developer powinien korzystać z edytora, w którym czuje się produktywny. Ale jest konkretny powód, dla którego wybrałem PyCharm do intensywnego developmentu w Pythonie. Edytory ogólnego przeznaczenia wymagają od ciebie zbudowania własnego środowiska z różnych pluginów. Dedykowane IDE zapewnia głęboką integrację out-of-the-box, która od razu rozumie składnię Pythona, zarządzanie pakietami i strukturę projektu. Kiedy konfigurujesz nowy projekt w Pythonie, twoim priorytetem jest izolacja. Jeśli zainstalujesz zależności bezpośrednio w systemowej instalacji Pythona, w końcu zaśmiecisz globalne pakiety i spowodujesz konflikty wersji między różnymi aplikacjami. Aby temu zapobiec, potrzebujesz wirtualnego środowiska. W PyCharm zaczynasz od utworzenia nowego projektu typu pure Python. Podajesz nazwę projektu i ścieżkę do katalogu. I to jest najważniejsza część. Zamiast przechodzić do terminala, żeby ręcznie utworzyć i aktywować środowisko, PyCharm wyświetla prompt, abyś skonfigurował interpreter Pythona bezpośrednio w oknie nowego projektu. Wybierasz opcję utworzenia nowego wirtualnego środowiska, wskazujesz bazową instalację Pythona na swoim komputerze, a IDE zajmuje się resztą. Buduje odizolowane środowisko i automatycznie podpina je pod twój nowy workspace. Za każdym razem, gdy otwierasz ten projekt, odpowiednie zależności są już aktywne. Po utworzeniu projektu zauważysz ukryty folder o nazwie dot idea w roocie twojego workspace'u. Ludzie często mylą to, co znajduje się w tym katalogu, z globalnymi ustawieniami samego edytora. Globalne ustawienia IDE sterują takimi rzeczami jak motyw wizualny czy niestandardowe skróty klawiaturowe dla całej twojej pracy. Katalog dot idea działa zupełnie inaczej. Ściśle izoluje ustawienia na poziomie projektu. Zapamiętuje, z którego wirtualnego środowiska korzysta dany projekt, mapuje project roots i przechowuje nadpisania stylu kodu specyficzne dla tego codebase'u. Ponieważ te ustawienia definiują, jak działa projekt, katalog dot idea powinien być zazwyczaj zacommitowany do version control. Dzięki temu, gdy twój współpracownik sklonuje repozytorium, jego edytor natychmiast rozpozna strukturę projektu bez ręcznej konfiguracji. Jeśli podobają ci się te odcinki i chcesz wesprzeć podcast, możesz wyszukać DevStoriesEU na Patreonie. Największą wartością dedykowanego IDE podczas konfiguracji jest to, że bierze na siebie żmudne obciążenie poznawcze związane z zarządzaniem środowiskiem, dzięki czemu możesz poświęcić czas na faktyczne pisanie business logic. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. PyCharm Dedicated Python IDE, odcinek 2 z 5. Większość programistów nadal odpala terminal, żeby uruchomić testy i wygenerować raporty coverage. Nie zdają sobie sprawy, że ich IDE ma wbudowaną akcję, która jednym kliknięciem wizualnie podświetla dokładnie te linijki kodu, które właśnie pominęli. Dzisiaj bierzemy na warsztat ukryte perełki: Run Configurations i Code Insight. PyCharm nie czyta twojego kodu po prostu jako plain text. Parsuje twoją logikę strukturalną pod kątem najnowszych propozycji ulepszeń Pythona, znanych jako PEP. Jeśli używasz structural pattern matching wprowadzonego w PEP 634, edytor aktywnie waliduje twoje statementy match i case. Upewnia się, że twoje patterny są wyczerpujące i ostrzega cię, jeśli jakiś case jest nieosiągalny. Robi dokładnie to samo dla nowej składni type parameter z PEP 695. IDE natychmiast natywnie flaguje mismatche generic types, na długo przed tym, zanim w ogóle spróbujesz odpalić kod. Kiedy IDE zauważy nieefektywność albo potencjalne ulepszenie, oferuje Intention Actions. Wciskając Alt i Enter, albo Option i Return na Macu, wywołujesz listę context-aware sugestii. To nie są zwykłe operacje find-and-replace na tekście. Ponieważ PyCharm rozumie pod spodem syntax tree twojego pliku w Pythonie, może bezpiecznie przepisać złożoną zagnieżdżoną pętlę w czyste dictionary comprehension, bez psucia twojej logiki. Uderza w konkretny node w strukturze twojego kodu. Kiedy twój kod jest już napisany i dopracowany, musisz go wykonać. Większość ludzi klika standardowy, zielony przycisk play na głównym toolbarze i na tym kończy eksplorację. Ale widget Run na górze okna kryje w sobie o wiele większą moc. Obok przycisku play znajduje się menu More Actions, reprezentowane przez trzy kropki. Otwarcie tego menu odkrywa zupełnie inne sposoby na odpalenie twojej aplikacji. To tutaj znajdziesz opcje, żeby uruchomić swój kod z profilerem albo wykonać swój test suite z włączonym coverage. Wielu programistów błędnie uważa, że muszą ręcznie zainstalować narzędzie do coverage, odpalić je z command line'a i czytać output w terminalu, żeby zobaczyć wyniki swoich testów. Wcale nie musisz tego robić. PyCharm ma code coverage wbudowany bezpośrednio w krok uruchamiania. Kiedy wybierzesz Run with Coverage z menu More Actions, IDE wykonuje test suite w tle. A potem nakłada wyniki bezpośrednio w twoim edytorze. Dostajesz zielone i czerwone markery w gutterze, tuż obok numerów linijek. Zielony oznacza, że linijka została przetestowana, a czerwony, że została całkowicie pominięta podczas uruchamiania. Żeby ten workflow był płynny, użyj popupu Run. Wciśnięcie Alt Shift F10 na Windowsie i Linuxie, albo Control Option R na macOS, wywołuje pływające menu wszystkich konfiguracji twojego projektu. Oto kluczowy insight. Nie musisz dotykać myszki, żeby zmienić sposób, w jaki odpala się twoja aplikacja. Powiedzmy, że refaktorujesz ogromną, złożoną funkcję. Robisz swoje zmiany strukturalne używając Intention Action. Zamiast przechodzić do zakładki terminala, wywołujesz popup Run, wybierasz swój test suite i natychmiast odpalasz go z coverage. W ciągu kilku sekund weryfikujesz, że twój refactoring działa, a twoja nowa logika jest nadal w pełni przetestowana. Prawdziwa wartość dedykowanego IDE to nie tylko szybsze pisanie kodu, ale zacieśnienie feedback loopa między zmianą linijki kodu a dokładną wiedzą, jak się ona zachowuje po uruchomieniu. Dzięki za spędzenie ze mną tych kilku minut. Do następnego razu, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. PyCharm Dedicated Python IDE, odcinek 3 z 5. Jeśli twój kod jest zaśmiecony printami tylko po to, żeby sprawdzić wartość zmiennej, marnujesz godziny developmentu. Czas przestać zgadywać i zacząć obserwować. Dzisiaj omówimy opanowanie debuggera: state i breakpointy. Wyobraź sobie, że szukasz buga w skrypcie do transformacji danych, gdzie wartość dictionary w tajemniczy sposób zmienia się na None. Jeśli używasz printów, musisz napisać printa, odpalić skrypt, sprawdzić konsolę, zorientować się, że wypisałeś złą rzecz, i zacząć od nowa. Debugger całkowicie zastępuje tę pętlę. Pozwala ci zapauzować wykonywanie programu, sprawdzić memory heap, wartości zmiennych i stany threadów, bez jakiejkolwiek modyfikacji source code'u. Na początek ustawiasz line breakpoint. Robisz to, klikając w lewy gutter edytora, obok numeru linijki, w której podejrzewasz, że zaczyna się problem. Pojawia się czerwona kropka. Następnie odpalasz skrypt w debug mode, klikając ikonę buga zamiast standardowego przycisku run. Twój program wykonuje się normalnie, aż dotrze do twojego breakpointa. Wykonywanie pauzuje dokładnie przed uruchomieniem tej zaznaczonej linijki kodu. Kiedy program się zapauzuje, automatycznie otwiera się okno narzędzia Debug. I tu jest kluczowa sprawa. Panel Variables w tym oknie daje ci interaktywną mapę application state na żywo. Zobaczysz każdą zmienną, która jest aktualnie w scope. Możesz rozwinąć swoje dictionary, żeby zobaczyć wszystkie jego klucze i wartości w tej konkretnej mikrosekundzie. Masz też dostęp do narzędzia Evaluate Expression. Pozwala ci ono na odpalenie dowolnego kodu w Pythonie w trakcie działania programu. Jeśli chcesz szybko odpalić list comprehension na swoich danych albo sprawdzić złożony warunek, wpisujesz to w evaluator. Przetwarza to używając obecnego application state i zwraca wynik. Możesz nawet użyć tego narzędzia, żeby nadpisać wartość zmiennej w locie, testując potencjalnego fixa na miejscu, bez restartowania debug session. Możesz też spojrzeć na panel Frames, który reprezentuje twój call stack. Pokazuje dokładną sekwencję wywołań funkcji, które doprowadziły do twojego obecnego breakpointa. Wybranie innego frame'a pozwala ci sprawdzić lokalne zmienne funkcji, które wywołały twój obecny kod. Po zapauzowaniu, musisz posuwać wykonywanie linijka po linijce, żeby wyizolować moment, w którym wartość dictionary zmienia się na None. Nazywa się to steppingiem. Developerzy często mylą step over ze step into. Step Over oznacza wykonanie obecnej linijki i zapauzowanie na następnej linijce w obecnym pliku. Jeśli obecna linijka zawiera wywołanie funkcji, Step Over odpala całą tę funkcję w tle i wrzuca cię do następnej linijki w twoim aktywnym pliku. Używasz tego, kiedy ufasz, że funkcja działa poprawnie. Step Into oznacza wejście do środka wywołania funkcji. Debugger przenosi wykonywanie do pierwszej linijki tej nowo wywołanej funkcji, pozwalając ci śledzić jej wewnętrzną logikę linijka po linijce. Używając breakpointów i steppingu, kontrolujesz flow. Pauzujesz tuż przed podejrzewanym błędem, robisz step into do funkcji transformacji i patrzysz, jak aktualizuje się panel Variables. Dokładna linijka, która wykonuje się tuż przed tym, jak wartość dictionary staje się None, to źródło twojego buga. Debugger to nie tylko narzędzie do znajdowania crashy. To interaktywna soczewka, która daje ci absolutną kontrolę nad flow programu i memory state. To wszystko w tym odcinku. Dzięki za słuchanie i buduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. PyCharm Dedicated Python IDE, odcinek 4 z 5. Kod asynchroniczny sprawia, że twoje aplikacje są niesamowicie szybkie, aż do momentu, gdy cichy deadlock zamrozi wszystko i nie zostawi absolutnie żadnego śladu błędu. Dowiedzenie się, która dokładnie coroutine utknęła, jest niezwykle trudne. Rozwiązaniem w PyCharm jest wizualizacja kodu asynchronicznego: Concurrency Diagram. Kod asynchroniczny jest trudny do debugowania, ponieważ pojedynczy event loop stale przełącza się między taskami. Jeśli zbudujesz asynchroniczny web scraper i nagle jego wykonanie zajmie dziesięć minut zamiast dziesięciu sekund, standardowy logging jest w większości bezużyteczny. Zwykłe printy wypluwają tylko chaotyczną ścianę przeplatającego się tekstu. Wiesz, że task czeka, ale nie wiesz który ani dlaczego. Możesz pomyśleć, że potrzebujesz tu standardowego CPU profilera. Otóż nie. Standardowy CPU profiler powie ci, która funkcja zużyła najwięcej mocy obliczeniowej. Funkcja concurrency visualization działa inaczej. To specjalistyczne narzędzie zaprojektowane specjalnie do śledzenia stanów threadów i event loopów asyncio w czasie. Pokazuje ci, kiedy twój kod nie robi absolutnie niczego. Dostęp do tej funkcji uzyskasz przez Run widget na górze twojego IDE. Otwórz menu More Actions dla swojej run configuration i wybierz opcję profilowania z Concurrency Visualization. PyCharm wykona twój kod, a następnie wygeneruje szczegółowy diagram w dedykowanym tool window. W tym oknie wybierz zakładkę Asyncio graph. To właśnie tam dzieje się cała wizualizacja. Interfejs wyświetla oś czasu. Każdy poziomy track reprezentuje event loop lub thread. Wzdłuż tych tracków PyCharm rysuje bloki reprezentujące twoje coroutines. Długość bloku pokazuje, jak długo dana coroutine istniała. I tu robi się ciekawie. Każdy blok na osi czasu jest oznaczony kolorem na podstawie jego dokładnego stanu w tej konkretnej milisekundzie. Jeden kolor oznacza, że coroutine aktywnie działa i zużywa CPU. Inny kolor pokazuje, kiedy czeka, na przykład na odpowiedź z sieci lub odczyt pliku. Jeszcze inny kolor podkreśla, kiedy thread jest całkowicie zablokowany. Zastosuj to do scenariusza z zawieszonym web scraperem. Zamiast zgadywać, dlaczego scraper utknął, odpalasz concurrency visualization. Patrzysz na Asyncio graph i widzisz dziesięć coroutines odpalonych do pobierania stron. Dziewięć z nich wyświetla się jako jednolity blok w kolorze oznaczającym czekanie. Możesz kliknąć w te bloki, żeby zobaczyć, jaką dokładnie funkcję reprezentują. Natychmiast zauważasz, że wszystkie utknęły, czekając na pojedynczy network lock, którego poprzednia coroutine nie zdołała zwolnić. Widzenie tych stanów w czasie rzeczywistym, natywnie w IDE, to ogromna przewaga nad ręcznym debugowaniem. Zmienia to twoją perspektywę z czytania sekwencyjnych linijek kodu na oglądanie rzeczywistych relacji w czasie. Znajdujesz deadlocki nie poprzez śledzenie błędów logicznych w głowie, ale fizycznie zauważając zablokowane kolory i puste luki na wizualnym grafie. Najważniejszy wniosek jest taki, że asynchroniczne bugi to zazwyczaj problemy z timingiem i stanem, a Concurrency Diagram tłumaczy te niewidoczne problemy z timingiem na przejrzystą, wizualną mapę. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. PyCharm Dedicated Python IDE, odcinek 5 z 5. Udostępnianie ekranu sprawdza się podczas prezentacji, ale gdy skomplikowana migracja bazy danych wywala się lokalnie, patrzenie na stream wideo niewiele pomaga. Oboje musicie mieć ręce na klawiaturze i bezpośrednio wchodzić w interakcję z zepsutym środowiskiem. I to jest dokładnie to, co rozwiązuje Swarm Programming przy użyciu JetBrains Code With Me. Code With Me to wbudowany feature do zdalnego, wspólnego developmentu. Zamienia twoje lokalne IDE we współdzielony workspace do swarm programmingu, mentoringu i wspólnego debugowania. Wyobraź sobie scenariusz, w którym junior w zespole męczy się z migracją bazy danych, która wywala się tylko na jego specyficznym, lokalnym setupie. Zamiast kazać mu pushować zepsuty kod, albo próbować tłumaczyć komendy w terminalu przez calla, może odpalić zdalną sesję prosto ze swojego IDE. Cały setup opiera się na wyraźnej relacji hosta i gościa. Host to osoba udostępniająca swój projekt. Musi mieć zainstalowanego i odpalonego PyCharma. Panuje błędne przekonanie, że każdy, kto dołącza do sesji, też potrzebuje własnej, płatnej licencji na PyCharma. Wcale tak nie jest. Goście po prostu dostają link z zaproszeniem wygenerowany przez hosta. Kiedy klikasz w ten link jako gość, twoja przeglądarka automatycznie pobiera i otwiera JetBrains Client. To lekka aplikacja, która wygląda i zachowuje się prawie dokładnie tak samo jak pełne IDE PyCharma, ale nie przetwarza niczego lokalnie. Cała czarna robota, indeksowanie i sprawdzanie składni dzieje się na maszynie hosta. Dostajesz pełne, natywne doświadczenie z kodowania bez konieczności klonowania kodu źródłowego na swój dysk. Kiedy otwierasz swoją maszynę dla innego deva, bezpieczeństwo i granice mają znaczenie. Host ma szczegółową kontrolę nad tym, co mogą robić goście. Konfigurujesz to przed wygenerowaniem linku. Dostęp read-only oznacza, że gość może przeglądać pliki i śledzić twój kursor, ale nie może niczego zmienić. Uprawnienie edit files pozwala mu pisać razem z tobą w czasie rzeczywistym. Full access oddaje mu klucze, pozwalając gościowi na wykonywanie kodu, odpalanie testów i bezpośrednią interakcję z twoim lokalnym terminalem. Możesz zmieniać te uprawnienia w locie, podczas trwania sesji. I tu jest kluczowa sprawa. Nie udostępniasz tylko plików tekstowych; udostępniasz całe środowisko runtime. Jeśli junior odpala lokalny web server na porcie 8000, żeby przetestować swoją migrację, zdalny senior normalnie nie ma do niego dostępu. Code With Me ma wbudowany feature port forwarding, który to naprawia. Host określa lokalny port do udostępnienia. JetBrains Client binduje wtedy ten sam port na maszynie gościa. Senior może otworzyć swoją własną, lokalną przeglądarkę, wejść na localhost na porcie 8000 i wejść w interakcję z aplikacją działającą na maszynie hosta. Collaborative debugging działa najlepiej, kiedy wyeliminujesz tarcie związane z odtwarzaniem zepsutego stanu. Dzięki Code With Me całkowicie omijasz setup środowiska i wspólnie naprawiacie rzeczywisty problem, dokładnie tam, gdzie on występuje. Tym samym kończymy naszą serię. Zachęcam cię do przejrzenia oficjalnej dokumentacji JetBrains, wypróbowania tych narzędzi w praktyce, albo odwiedzenia DEV STORIES DOT EU, żeby zasugerować tematy do przyszłych serii. Dzięki za spędzenie ze mną tych kilku minut. Do usłyszenia następnym razem, trzymaj się.