Unknown error: cannot get automation extension

Jakiś czas temu znalazłem taki błąd w logach z uruchomienia paczki testów selenium.

Unknown error: cannot get automation extension

A w konsoli jedynie:

Po krótkich poszukiwaniach okazało się, że linijka która powodowała to zachowanie to:

webDriver.Manage().Window.Maximize();

No i teraz mamy dwie opcjie, pierwsza to najbardziej oczywista – aktualizacja ChromeDriver-a z wersji 2.24 (na której to się pokazało) do najnowszej – aktualnie 2.29. Albo jeśli z jakiś powodów nie możemy/nie chcemy zaktualizowac ChromeDrivera to można inaczej zmaksymalizować okno:


var options = new ChromeOptions();
options.AddArgument("start-maximized");
_webDriver = new ChromeDriver(Configuration.WebDriversPath, options);

 

Więc jak trafisz taki błąd, to może właśnie masz tutaj rozwiązanie 🙂 Powodzenia

Moje narzędzia do obsługi repozytorium kodu

Serii o podstawach ciąg dalszy. W ostatnim wpisie pisałem o najważniejszym artefakcie czyli o historii produktu zawartej w repozytorium kodu. Teraz pora zobaczyć na narzędzia. Bez odpowiednich* narzędzi praca jest po prostu mozolna i nieefektywna. Ponieważ aktualnie moim jedynym repozytorium kodu jakiego używam to git (zarówno w pracy jak i podczas przeprowadzanych szkoleń) to przedstawione poniżej narzędzia służą do pracy z gitem właśnie ale pewnie część z nich będzie pracować z innymi repozytoriami – sprawdź jeśli jeszcze nie używasz gita.

Konsola jako podstawowy klient do repozytorium kodu

Cmder to jedna z najlepszych konsoli na Windowsa czyli Conemu ale ubrana w customizacje dzięki czemu jest ładna i mocarna. W kontekście obsługi repozytorium kodu… posiada wbudowanego klienta git. Pobierasz cmder-a, rozpakowywujesz i tyle, masz i konsolę i gita. Nic więcej nie trzeba instalować, kombinować.

 

cmder jako najlepsze podstawowe narzędzie do obsługi gita

 

Plus jest taki, ze na bieżąco widzimy na jakiej gałęzi jesteśmy oraz czy mamy jakieś zmiany (wówczas napis master na rycinie powyżej byłby czerwony). Mamy obsługę powershella, posh gita i wielu wielu więcej ale dla mnie osobiście jedna z najlepszych rzeczy to gl czyli przegląd historii – z kolorkami i w ogóle.

przeglądanie historii w gicie

 

IDE musi rozumieć kontekst repozytorium kodu

Nie wyobrażam sobie pracy w IDE bez obsługi repozytorium kodu. Na szczęście wszystkie 3 narzędzia (Visual Studio, Visual Studio Code, InteliJ – Webstorm, Rider, PyCharm),  których używam mają to wbudowane. Ponieważ większość czasu spędzam w Visual Studio to lista moich priorytetów:

  1. chcę widzieć w jakim stanie są pliki,
  2. chcę mieć podgląd zmian od ostatniego commitu pod ręką,
  3. chcę mieć annotate/blame pod ręką,
  4. chcę mieć pod ręką możliwość powrotu do działającego kodu.

 

Super proste i super wygodne przeglądanie historii

Tak jak wcześniej pisałem historia to jedna z najważniejszych artefaktów produkcji oprogramowania. Zatem jak ją łatwo przeglądać? Niby wszystkie narzędzia coś tam mają ale dla mnie jest jedno super świetne narzędzie, które po pierwsze robi to co ma robić świetnie a po drugie jest pod ręką – w moim IDE z którego nie chcę wychodzić jak nie ma takiej potrzeby.

 

To narzędzie to CodeLineage i jak dla mnie to jest mistrz w przeglądaniu historii. Łatwo mogę wybrać dwa dowolne punkty historii i oglądać co się zmieniło. Szybko, wygodnie i w punkt.

Podsumowanie (TL;DR;)

Trzy dla mnie podstawowe narzędzia to Cmder, Visual Studio i CodeLineage. Rzeczy, których nie potrafię zrobić z gitem z poziomu konsoli robię z poziomu SourceTree.

 

*) dla każdego odpowiednie narzędzie oznacza coś innego (ale wiadomo, że pewne narzędzia są jedyne słuszne 😉 )

Repozytorium kodu a w nim jeden z najważniejszych artefaktów

hitoria kodu zapisana w repozytorum

Repozytorium kodu to jedno z podstawowych narzędzi programisty, bez którego żaden profesjonalista nie może się obejść. W nim jeden z najważniejszych produktów jaki tworzymy obok głównego aplikacji.

Historia produktu zapisana w repozytorium kodu

Tworząc aplikację z każdym commitem tworzy się historia. Tworzy się ciąg kroków, jakie doprowadziły aplikację do stanu dzisiejszego. To co możemy w tej historii wyczytać jest czasem bardzo cenne. Kiedy? Po pierwsze wtedy, gdy chcemy przypomnieć sobie co zrobiliśmy od wydania ostatniej wersji. Po drugie gdy chcemy poprawić jakiś błąd.

Release Notes z historii commitów

Pracując w zespole większym niż jednoosobowym i wydając kolejne wersje (bez względu czy to jest aplikacja pudełkowa, webowa czy usługa) często potrzebujemy śledzić co w kolejnych wersjach zostało wydane. Historia kolejnych commitów staje się w takiej sytuacji bardzo pomocna – oczywiście przy założeniu, że dajemy przyzwoite nazwy do commitów – i zakładam, że na dzień dzisiejszy mało osób jest tak nierozsądnych aby robić commity bez odpowiednich komunikatów. Można pójść nawet dalej. Jeśli mamy jakiś sensowny automatyczny build to możemy z automatu tagować kolejne wydania wersji i wysyłać listę commitów do osób odpowiedzialnych za to co się dzieje z takim artefaktem jak wydanie wersji później.

Historia jako narzędzie do debugowania

Drugie zastosowanie historii commitów jest dużo ciekawsze z punktu widzenia developera. Ile razy zachodziłeś w głowę dlaczego ktoś napisał kawałek kodu tak a nie inaczej? Dlaczego ktoś zrobił taki błąd? Czasem kawałek kodu potrafi być tak zagmatwany, że nie da się go zrozumieć, czasem tak głupio napisany, że aż niemożliwe, żeby autor napisał takie cudo na trzeźwo. Wtedy przychodzi na ratunek historia i opcja blame lub annotate (w zależności jakich narzędzi używasz). Ta opcja pozwala sprawdzić, kto ostatni dotykał każdej kolejnej linki w kodzie.

Blame i annotate

Dzięki temu bardzo szybko namierzymy osobę, która zostawiła kod w takim stanie. Warto zastanowić się, dlaczego kod został napisany tak a nie inaczej. Czasem wystarczy przeczytać commit message a czase trzeba zapytać osobę, która ostatnia go edytowała. Czasem dowiemy się, że kod powstał w jakiejś pomroczności i to jest po prostu zepsute ale czasem odkryjemy, że były jakieś ważne powód. Czasem to jakieś dziwne wymaganie klienta a czasem dziwne zachowanie frameworka czy biblioteki. Pewnie ktoś stwierdzi, że można wtedy zostawić komentarz – ale komentarze mają tą brzydką cechę, że gniją  a bądźmy szczerzy, kto refaktoryzuje komentarze – to się nie sprawdza.

Do czego jeszcze może się przydać historia?

A choćby do tego, aby raz na jakiś czas pooglądać kod z lotu ptaka i zobaczyć ile pracy i energii włożyliśmy w stworzenie aplikacji puszczając na całym repozytorium narzędzie gource które pięknie wizualizuje kolejne commity w czasie – warto wybrać się w taką wycieczkę.

A Tobie do czego jeszcze przydaje się historia commitów w Twoim repozytorium?