Pokazywanie postów oznaczonych etykietą IDEA. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą IDEA. Pokaż wszystkie posty

poniedziałek, 2 lutego 2015

ChamberConf wrażenia jako organizator, prelegent i uczestnik w jednym

W końcu się zebrałem, aby napisać relację z ChamberConf. Była to pierwsza konferencja organizowana przez Wrocławski JUG. Sam również po raz pierwszy miałem okazję uczestniczyć w organizacji takiego wydarzenia. Ostatnie 2 tygodnie przed wydarzeniem do łatwych nie należały...

Z założenia konferencja miała być bez sponsorów, czyli bez wszelakich konkursów, stoisk, prezentów itp. Początkowo konferencja była planowana na 65 osób, ale ostatecznie wyszło 80. Miejsce było niezwykłe, bo to były psychiatryk (gdzieś niedaleko jest jeszcze działający oddział), a jednocześnie bardzo ładny zamek, z dala od wielkich miast i cywilizacji. Konferencja trwała dwa dni, ale sporo osób przyjechało już w piątek wieczorem, więc nieoficjalnie zaczęło się trochę wcześniej.

Na pierwszej prezentacji w sobotę Tomka Borka i Jacka Jagieły pt. To nie zawsze wina aplikacji, robiłem za pilot do przełączania slajdów, ponieważ żaden wskaźnik nie chciał akurat współpracować z Ubuntu. Slajdy można sobie przejrzeć na prezi.com, jak i na slideshare. Z prezentacji wynikało, że należy pamiętać o monitoringu aplikacji i infrastruktury, bo często problemy z wydajnością nie leżą w naszym kodzie. Fajne było zadawanie pytań na koniec przez prelegentów do publiczności, czyli w odwrotnym kierunku niż zwykle.

Następnie Adam Warski opowiadał o Reactive Manifesto z użyciem Akki. Było trochę wstępu teoretycznego i sporo kodowania na żywo. Występ się trochę przedłużył, ale zależało nam na tym, aby konferencja nie miała sztywnych ram.

Następnie Konrad Malawski opowiadał o algorytmach głosowania w sieci. Było m.in. o Paxosie (którego prawie nikt nie rozumie), jak i jego uproszczonych wersjach. Początkowo bałem się, że to będzie prezentacja czysto akademicka, ale koniec końców okazało się, że bodajże raft consesus jest gdzieś tam w Akkce zaimplementowany.

Następnie był obiad i ostania prezentacja pierwszego dnia, Michała Bartyzela pt. Z czym mierzą się zespoły? Michał opowiadał sporo swoich doświadczeń i trudności jakie spotykamy w naszej pracy, oraz jak zmieniał się jego światopogląd na przestrzeni lat.

Następnie było unconference, czyli coś co nie wiedzieliśmy czy się uda czy nie. Ale wychodzi na to że się udało. Było sporo pytań do Konrada, rozmów o pracy zdalnej, CQRSie i inne, a to wszystko w luźnej atmosferze. Później całość się przeniosła na kolację i dalsze rozmowy z ludźmi zwłaszcza nowopoznanymi.

Drugi dzień rozpocząłem od zapowiadanego morsowania. Niestety nikt chętny się nie zgłosił, chociaż o 2:00 w nocy ktoś się podobno deklarował. Może za mało przypominałem uczestnikom o tym temacie...


Drugiego dnia udałem się na Archi-Katę do Tomka Borko. Warsztat był na kartkach bez użycia komputerów, ale zmuszał do sporego myślenia, a później dyskusji i oceniania prac innych. Bardzo fajny warsztat.

Równolegle do warsztatów była ścieżka z prezentacjami. Tam frekwencja była mniejsza, ale podobno bardzo sprzyjało to żywej dyskusji.

Po przerwie obiadowej sam prowadziłem warsztaty. Jak się okazało, był to jedyny temat związany z Java, gdyż inne były o Scali, architekturze lub miękkie. Chyba trzeba będzie zmienić Java User Group na JVM User Group. Warsztat był rozszerzoną powtórką z Warsjawy. Sam na początku warsztatu się czegoś nowego nauczyłem, a mianowicie poznałem: Presentation Assistant, dzięki któremu można było wyświetlać wciskane skróty na ekranie. Kiedyś jak szukałem takiego narzędzie pod windę, to każde okazywało się jakieś kiepskie. A wspomniany plugin pokazywał skróty w wersji na Winde i Mac'a.

Implementowaliśmy ten sam problem co na Warsjawie, czyli StringCalculator. I jak doszliśmy do wydarzeń regularnych, to znów zaczeły się schody. Okazje się, że jak "ma się jakiś problem, który rozwiązujemy za pomocą regexpa, to de facto rozwiązujemy dwa problemy". Jakoś w końcu udało się wybrnąć z tego, ale nie było łatwo. Sam kilka dni przed konferencją zaimplementowałem problem, rozwiązanie (pewnie nieidealne) dostępne na githubie: mstachniuk/StringCalculatorKata. A slajdy poniżej:



Szkoda tylko, że nie wszyscy uczestnicy dotrwali do końca, ale wiadomo - niedziela i trzeba było wrócić z tego końca świata do domu. Mój warsztat trochę się przedłużył, ale to ze względu na masę pytań. Na koniec było czuć zmęczenie, ale i zadowolenie.

Podsumowując konferencję wypadła bardzo dobrze. Pierwszy dzień był mocny i miał służyć owocnym rozmowom podczas unconference. Ten cel został osiągnięty. Drugi dzień wypadł już trochę słabiej, więc pewnie można coś w nim poprawić. Można to ewentualnie tłumaczyć znakomitym pierwszym dniem. Mam nadzieję do zobaczenia za rok!

środa, 14 stycznia 2015

Duplikowanie bloku kodu w IntelliJ Idea

Dzisiaj mam do zaprezentowania mały lifehack w IntelliJ Idea. Wyszło to podczas przygotowywania (a raczej odświeżania) mojego warsztatu na konferencję ChamberConf'15, której też jestem współorganizatorem (wraz z ekipą z Wrocławskiego JUGa).

Otóż gdy się przesiadałem (dawno dawno temu) z Eclipse'a do Idei, to z początku denerwował mnie sposób duplikowania linii w kodzie. Ale nie o sam skrót klawiaturowy mi chodzi (Ctrl + D który to w starym środowisku usuwał linię), a o sposób duplikowania zaznaczonego kodu. A działa to tak:


Wiem, że mógłbym szybciej zaznaczyć dany fragment za pomocą Ctrl + W, ale wówczas efekt końcowy jest mniej zauważalny.

Generalnie powielany fragment kodu jest wstawiany zaraz za zaznaczeniem. Kiedyś bardzo mnie to denerwowało ale z czasem się przyzwyczaiłem i jakoś z tym żyłem. Ale dzisiaj rano znów zaczęło mnie to irytować... Zacząłem przeglądać YouTrack dla Idei i pogrzebałem trochę w ustawieniach.


Jak patrzymy na mapowanie klawiszy to mamy "Duplicate Line or Block" jak i "Duplicate Lines". Pod pierwszą pozycję jest podpięty skrót Ctrl + D. Gdy go stamtąd usuniemy i użyjemy w drugiej opcji, to otrzymamy ostrzeżenie o konflikcie:



Klikamy na "Leave" i uzyskujemy poniższy efekt działania Ctrl + D:


Jak widać, ten sam (tak samo zaznaczony) fragment kodu, po wciśnięciu magicznej kombinacji, wstawia się w nowej linii!

Mam nadzieję, że ten prosty wpis się spodobał. Jak chcesz poznać więcej trików, to zapraszam na wspomnianą już konferencję: ChambeConf'15, lub odezwij się bezpośrednio do mnie.

poniedziałek, 1 grudnia 2014

Warsjawa 2014 podsumowanie nr 2 i dawanie feeedback’u

W moim przedostatnim wpisie: Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty umieściłem materiały z których korzystałem podczas tych warsztatów i opisałem swoje pierwsze wrażenia. Teraz czas na kolejną ostatnią część podsumowania, ponieważ już jakiś czas temu spłynęły do mnie wyniki ankiety przeprowadzonej przez organizatorów. A jest się czym pochwalić :-D Poniżej zamieszczam fragmenty korespondencji, którą otrzymałem od organizatorów.

Odnośnie Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych


Your workshop was among best workshops of Warsjawa 2014! 
Here comes the results: 
number of feedbacks: 8 
average grade (1 to 5, higher is better): 4.63 
feedback comments: 
- A lot of knowledge presented, but a bit too fast. 
- Bardzo fajne i przydatne warsztaty - fajnie zorganizowane 
- Z warsztatów jestem bardzo zadowolony. Poznałem nowe, lepsze metody testowania, których mam nadzieje użyć w codziennej pracy. Projekt na githubie znacznie ułatwił cala sprawę. Dziękuje :) 
- Workshop was as described. From a begginer point of view approach : from simplest libraries to most helpful was realy good.


Co to dla mnie oznacza? Że dostałem 5 głosów z oceną 5 i 3 z oceną 4, lub jakiś inny wariant dający sumę 37. Przy ośmiu głosach daje to właśnie oceną 4.63 (a dokładniej 4.625). Bardzo się cieszę tak wysoką oceną, która w tym momencie trochę rekompensuje ogrom trudu włożonego w przygotowanie tegoż warsztatu.

Odnośnie Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Here comes the results: 
number of feedbacks: 6 
average grade (1 to 5, higher is better): 4.5 
feedback comments: 
- Prawdziwe warsztaty, bardzo ciekawie poprowadzone na konkretnym przykładzie. Nie mam do nich żadnych uwag. 
- Miałem iść na C/C++ in Android Apps. Jednak mnogość instalowania narzędzi zniechęciła mnie (była sobota 16:00)... dosłownie na 1 minutę przed startem warsztatu przyszedłem tutaj. I nie żałuje. Skrótów wszystkich nie zapamiętałem, ale wiem dokładnie co można za ich pomocą osiągnąć. Formuła warsztatu wymagała ciągłego zaangażowania oraz umożliwiała świetną zabawę w poprawienie kodu kogoś innego :) Prelegent bardzo pozytywnie nastawiony do życia i moim zdaniem niezły kozak jeżeli chodzi o Intelli :) 
- Very good workshop, I learned a lot about the Intellij Idea.

Tutaj ocena nie jest już tak wysoka, ale i tak jest dobrze. Zwłaszcza że warsztat był w sobotę pod koniec dnia i większość już pewnie myślała o wieczornym piwie. Bardzo mnie tutaj ucieszyła druga opisowa opinia jednego z uczestników. Dzięki - kimkolwiek jesteś.

Podczas analizowania feedbacku od uczestników moich warsztatów naszły mnie jednak smutne przemyślenia. Ludzie bardzo niechętnie dają opinię zwrotną drugiej osobie! Trzeba się o nią wręcz dopraszać i ciągnąć za język. Szkoda, że system głosowania na Warsjawie nie zadziałał, bo on mógłby dać trochę szerszy obraz oceny warsztatu. A tak, to ankietę pokonferencyjną – jak widać powyżej – mało komu chce się wypełnić. Nie wiem czy to wynika z naszej introwertycznej natury, nieśmiałości, poprawności politycznej, czy z problemu z wyrażaniem swoich odczuć? Przecież na co dzień przekzujemy dalej swoje opinie na temat kodu naszych współtowarzyszy projektu. Przecież robicie Code Review? A może nie?

W każdym bądź razie prelegenci, czy też prowadzący warsztaty – zwłaszcza Ci poczatkujący – oczekują jakiejś zwrotnej opinii na temat swojej pracy! Wierzę w możliwość ciągłego udoskonalenia się i poprawiania swoich zdolności, aby kolejnym razem wypaść lepiej.

W jaki sposób wiec najlepiej zbierać konstruktywne opinie o sobie i swojej pracy? Jak masz jakieś pomysły to koniecznie pisz w komentarzach!

Chcę jeszcze dokonać publicznej konstruktywnej samooceny (aby dać przykład, jakie potknięcia warto wytykać) i napisać, co poszło mi nie tak na moich warsztatach, aby następnym razem nie popełnić tego samego błędu. Na pierwszym warsztacie zapomniałem puścić powitalny filmiki od organizatorów. Niestety, ale tuż przed samymi warsztatami musiałem trochę pozmieniać bazę w git’cie (mam na myśli rebase, ale nie mam pojęcia jak to można na polski przetłumaczyć), aby historia na publicznym repo nie wyglądała później tak:

Z tego względu gdzieś mi umknęła wiadomość od organizatorów, prosząca o puszczenie filmików. Sory!

Co do drugiego warsztatu, to trochę mniej się do niego przygotowałem (w sensie slajdów), ale na szczęście nie to było najważniejsze, co widać po ocenie. Ważne, że uczestnicy się świetnie bawili i wynieśli sporą wiedzę z warsztatu.

Błędem był jednak brak porządnej aplikacji na telefon / tablet, pokazującej odliczany czas i dającej sygnał dźwiękowy co określony interwał. W tym warsztacie było bardzo ważne, aby co 5 minut robić zmianę, ale mój budzik nie zawsze dzwonił, przez co niektórzy siedzieli dłużej przy klawiaturze. Jak ktoś ma godną polecenia aplikację, do tego na Androida, to czekam na info!

Również brak przerwy mniej więcej w połowie warsztatu był kiepskim pomysłem, gdyż to chyba szybko wymęczyło ludzi. W okolicach drugiej godziny, widziałem zmęczenie na twarzach uczestników. A przerwa tuż przed końcem warsztatów nie była wystarczająco odświeżająca.

Mogłem również się trochę lepiej przygotować z implementowanego problemu, aby w razie dojścia do ślepego zaułku (do którego doszliśmy), aby szybko z niego wyskoczyć na właściwe tory. Do poprawienia następnym razem.


Przy okazji konfitury, firma Spartez zorganizowała jeszcze konkurs dla uczestników. Zadania można było rozwiązać wcześniej online, aby nie tracić czasu na samej konferencji. Jak zobaczyłem pytania (a było ich 6), od razu wiedziałem kto wygra – i nie pomyliłem się. Mimo wszystko zostałem wyróżniony i dostałem gadżety firmowe. Niestety ucho od kubka się potłukło w transporcie, ale jakoś mi specjalnie na nim nie zależało. Liczy się satysfakcja, z rozwiązanych zadań.

Podsumowując, obydwie wysokie oceny z warsztatów motywują mnie do dalszego działania w sferze dzielenia się moją wiedzą z innymi. Jeśli więc chciałbyś, abym poprowadził któryś w/w warsztatów u Ciebie w mieście / w firmie, daj znać na priv – e-mail do mnie znajdziesz na tej stronie.

A jeśli nie miałeś/-aś okazji uczestniczenia w moich warsztatach podczas Warsjawy, to być może, niedługo będzie taka możliwość w okolicach Wrocławia. Po więcej szczegółów zapraszam na stronę: chamberconf.pl

poniedziałek, 29 września 2014

Warsjawa 2014, czyli ja jako prowadzący 2 warsztaty

W tym roku miałem okazję poprowadzić 2 warsztaty na Warsjawie. Wcześniej prowadziłem jedynie prezentacje (czy to w pracy czy na WrocławJUG), a w formie warsztatów to był mój pierwszy raz! I od razu 2 różne tematy!

Jak mi poszło? Uważam, że co najmniej dobrze. Wydaje mi się, że nie miałem większych potknięć, feedback zbierany od uczestników jest jak dotychczas pozytywny.


Podobne opinie słyszałem, gdy się podpytywałem uczestników, jak i przeczytałem w e-mailach. Pewnie coś więcej będę mógł się dowiedzieć (zwłaszcza liczę na uwagi krytyczne, aby wiedzieć co poprawić następnym razem), gdy uczestnicy wypełnią ankietę pokonferencyjną. Wszelakie e-maile i komentarze również mile widziane.

A tymczasem zamieszczam poniżej materiały z których korzystałem.

Upiększ swoje testy! Testowanie jednostkowe dla średniozaawansowanych.



Kod używany na warsztacie: https://github.com/mstachniuk/SolarSystem

Poznaj lepiej swoje srodowisko programistyczne i zwieksz swoja produktywnosc z IntelliJ Idea.

Kod napisany przez uczestników podczas warsztatów: https://github.com/mstachniuk/WarsjawaCodingDojo

Co do samej konferencji, to minusy (z punktu widzenia prelegenta):
- nie do końca przygotowane sale (rzutnik, nasłonecznienie, jakieś pudła)
- system do komunikacji z uczestnikami nie wysyła załączników i wiadomości nie dochodzą do wszystkich
- nie do końca udany pomysł ze szwendaniem się po knajpach po konferencji

A na plus:
- obecność zagranicznych spikerów
- wcześniejsza rejestracja dla prelegentów
- transparentnosć, co ile kosztowało
- długie przerwy, dobry timeline

I oby tak dalej, albo i jeszcze lepiej!

czwartek, 11 września 2014

Rusza rejestracja na tegoroczną Warsjawę oraz moje tematy

Już niedługo (21.09.2014 21:00) ruszy rejestracja dla uczestników Warsjawy - darmowej konferencji, która składa się z samych warsztatów! Liczba miejsc jest ograniczona, dlatego warto się spieszyć, zwłaszcza, że jest szansa na warsztaty, które będzie prowadził Venkat Subramaniam! Jest to założyciel Agile Developer, autor wielu książek jak i świetny prelegent, którego mieliśmy okazję wielokrotnie oglądać na polskich konferencjach. Styl jego prezentacji jest specyficzny, a o części jego wystąpień można przeczytać na moim blogu.

Dzięki wizycie Venkata w Warszawie, udało się go zaprosić także do Wrocławia i poprowadzi on wykład Programming with Lambda Expressions w ramach WrocJUG. Będzie również warsztat: Programming Concurrency - Workshop, ale na niego nie ma już miejsc, a lista oczekujących jest długa.

Jednocześnie zapraszam na warsztaty, które sam będę prowadził w ramach Warsjawy. Poniżej przedstawiam tematy, które będę prowadził, wraz z krótkim komentarzem.

Czas: Piątek, 26 września 2014 13:00
Temat: Upiększ swoje testy. Testowanie jednostkowe dla średnio zaawansowanych

Opis: Warsztat jest przeznaczony dla średniozaawansowanych programistów Java, którzy napisali już trochę testów i chcieliby je upiększyć. Podczas warsztatu będziemy ćwiczyć tworzenie ładnej sekcji given (za pomocą Builder'ów), jak i czytelniejsze zapisywanie assercji (za pomocą Hamcrest'a, FEST'a i AssertJ). Bedzie jeszcze o testowaniu wyjątków i testach parametrycznych. Warsztat będzie prowadzony po polsku, względnie może być po niemiecku;) Wymagane jest zabranie ze sobą własnego komputera ze skonfigurowanym środowiskiem programistycznym i opcjonalnie konto na GitHub'ie (do przesyłania gist'ów).

Być może, jak starczy czasu, będzie można poćwiczyć jeszcze inne rzeczy, ale to już zależy głównie od prędkości grupy, jak i zainteresowania tym, co będą chcieli usłyszeć uczestnicy.

Czas: Sobota, 27 września 2014 16:00
Temat: Poznaj lepiej swoje środowisko programistyczne i zwiększ swoją produktywność z IntelliJ Idea

Opis: Każdy programista powinien poświęcić 10 godzin na dogłębne poznanie swojego zintegrowanego środowiska pracy, aby móc z niego efektywnie (i efektownie) korzystać! A Ty ile czasu na to poświęciłeś? Warsztat jest przeznaczony dla programistów Java, korzystających z IntelliJ Idea, lub chcących się go nauczyć. Warsztat będzie miał formę Coding Dojo, podczas którego będziemy wspólnie pisać Katę i wzajemnie uczyć się korzystania z Idei bez użycia myszki. Warsztat będzie prowadzony po polsku, względnie może być po niemiecku;) Własny komputer nie jest wymagany, gdyż będziemy kodować wspólnie na jednym, podpiętym do rzutnika. Przyda się za to notatnik i długopis do zapisywania nowopoznanych kombinacji klawiszowych.

Na pomysł tego warsztatu wpadłem po tym, jak go z wielkim sukcesem przeprowadziłem w ostatnim projekcie. Po prostu, gdy udało się kupić IntelliJ Idea dla całego zespołu (o co bardzo ciężko walczyłem - skutecznie), musiałem wdrożyć kolegów w nowe środowisko. Wcześniej pokazywałem jedynie czym się różni Idea od Eclipse'a, ale to nie to samo co praktyka przy klawiaturze. Nie chciałem również słyszeć narzekań, że teraz trzeba się na nowo uczyć wszystkich kombinacji klawiszowych.

Zebrałem więc cały zespół, wyjaśniłem zasady i poszłooo! Było bardzo intensywnie, śmiesznie i co najważniejsze pouczająco. Ludzie wychodzili wówczas z sali z ugotowaną głową, ale widziałem później, że te warsztaty bardzo im pomogły. Zebrałem również bardzo pozytywne opinie na retrospektywie.

Mam nadzieję, że na Warsjawie będzie równie gorąco.

P.S. W razie jak byście chcieli się wcześniej zapisać na warsztaty, to przeczytajcie ten status.

czwartek, 17 lipca 2014

Wyższy poziom produktywności w IntelliJ Idea

Ostatnio natrafiłem na nagrania z konferencji Geekout z Estonii. Zainteresowała mnie 3cia prezentacja: Mouseless Driven Development by Hadi Hariri.


Prelegent (pracownik JetBains’a) opowiadał o tym jak efektywnie kodować bez użycia myszki. Myślałem, że już dostatecznie poznałem to moje ulubione środowisko developerskie, ale jak zobaczyłem pierwszą ciekawostkę, którą pokazał Hadi, to zacząłem robić notatki. A skoro notatki to już nie wiele trzeba, aby był wpis na bloga…

Uważam, że najlepszą metodą poznawania środowiska pracy, jest patrzenie jak korzystają z niego inni. I to może być przy okazji warsztatów typu Code Retreat, Coding Dojo czy innych hackathon'ów, lub właśnie oglądając screencasty i wystąpienia z konferencji. Zachęcam do obejrzenia powyższego video (choć ten efekt z przekrzywionym obrazem z rzutnika uważam za głupi), gdyż opisałem poniżej rzeczy dla mnie nowe, tudzież te wymagające mojego odświeżenia. Warto, przed dalszą lekturą tego wpisu, znać choć połowę skrótów z IntelliJIDEA_ReferenceCard.pdf, gdyż niżej będzie o bardziej zaawansowanych zagadnieniach. A więc do dzieła!

Jak wszyscy zapewne wiedzą (albo powinni wiedzieć), Ctrl + N otwiera klasy lub pliki (gdy dwa razy naciśniemy tą kombinację, lub Ctrl + Shift + N). I tutaj nazwę możemy podawać w szelaki sposób: CamelCase, snake_case (ale dla ułatwienia ze spacją), wspomagając się gwiazdką itd. Idea będzie szukać wszystkiego co pasuje i wyświetli w logicznym porządku. W Eclipse „jakoś tam” też to działa, ale o wiele gorzej.

Ale co mnie właściwie onieśmieliło, to gdy pisząc po nazwie klasy :<numer lini> (słownie: dwukropek i numer linii), plik zostanie otworzony na żądanej pozycji! Ciekawie działa również Alt + F1, które pozwala otworzyć nam plik np. w Project View, Structure, Exporatorze Windowsa, i w innych oknach. A chcąc otworzyć plik w osobnym oknie można zamiast Entera wcisnąć Shift + Enter. A jak chcemy wyszukiwać wszędzie, to możemy to zrobić za pomocą podwójnego naciśnięcia Shift. Część tych wskazówek zaczerpnąłem ze strony JetBrains’a: Navigating to Class, File or Symbol by Name, a część z opisanego na początku video.

Do wyszukiwania użycia jakiejś zmiennej lub metody, zawsze korzystałem z Alt + F7. Jest to skrót, który swoimi korzeniami sięga TotalCommandera, a nawet Norton Commandera. Podobnie jest zresztą z Shift + F6 - rename. Natomiast jak chcemy widzieć dolnego okienka z wynikami poszukiwań, możemy skorzystać z Ctrl + F7, które to skoczy nam do pierwszego wykorzystania i zaznaczy pozostałe. A jak byśmy chcieli podświetlić wykorzystanie wielu różnych zmiennych, to na każdej możemy skorzystać z Ctrl + Shift + F7. Jeszcze podobnie zachowuje się Ctrl + Alt + F7, które to pokazuje wyniki wyszukiwania w popupie. Poniżej przykłady z mojego projektu HamcrestVsFest.

Alt + F7

Ctrl + F7. Obiekt mercury jest tworzony w lini 10, ale po raz pierwszy jest użyty w linii 20.

Ctrl + Shift + F7. Tutaj wykonane na mercury, PlanetBuilder, RotationDirection i Gases.

Ctrl + Alt + F7

Dalej było o tym, jak zmaksymalizować przestrzeń na pisanie kodu. I tak prelegent, przekonywał nas, że można się obejść bez nawigation bara na górze ekranu.


To ten pasek, gdzie jest rozpisane, w jakim pakiecie i pliku aktualnie jesteśmy. Nie jest on nam potrzebny, bo możemy się dostać do niego za pomocą Alt + Home. Mi osobiście on nie przeszkadza, bo jest na tym samym poziomie, co ostatnio uruchamiana konfiguracja projektu, a to lubię widzieć.

Nie potrzebujemy również Tab’ek, gdy mamy wiele otwartych plików, bo przeglądanie ich i szukanie odpowiedniej po nazwie zajmuje wiele czasu.


Tak naprawdę potrzebujemy tylko Ctrl + E, które w bardziej czytelny sposób nam pokazuje, jakie pliki ostatnio przeglądaliśmy i szybciej je w ten sposób odnajdziemy. Jeśli zależy nam tylko na tych które ostatnio edytowaliśmy, to możemy skorzystać z Ctrl + Shift + E. Jest to ulubiony skrót prowadzącego prezentację do tego stopnia, że musi używać zewnętrznej klawiatury w laptopie, bo przycisk E mu się zepsuł. Przykłady użycia poniżej, a Tab'ki możemy całkowicie wyłączyć w ustawieniach.


Ctrl + E
Ctrl + Shift + E

Jak usunąć Tab'ki z otwartymi plikami.

Przeskakiwać pomiędzy poszczególnymi oknami w IntelliJ Idea można za pomocą Alt + <numer okienka>, widoczny przy jego nazwie. Niestety nie na wszystkie okienka wystarczyło numerków, więc jak chcemy np. dostać się do Mavena lub Bazy danych, to Ctrl + Tab jest twoim przyjacielem.

Ctrl + Tab

A jak już w ogóle byśmy chcieli tylko i wyłącznie kod widzieć, to warto się zapoznać z Prezentation Mode. Warto na Windowsie sobie zdefiniować skrót Ctrl + Shift + P jako wejście do tego trybu. Na pewno może się to przydać podczas prezentacji, jak i osobom lubiącym widzieć tylko kod na ekranie.

Następnie poznałem nowe znaczenie F4 w oknie projektu. Dotychczas używałem tego klawisza tylko do otwierania właściwości projektu, a w ten sposób można również otworzyć plik i automatycznie skoczyć do jego edycji. Jest to lepsze od oczywistego Entera, który tylko otwiera wybrany plik, ale fokus pozostaje na oknie projektu.

A co z operacjami typowymi dla myszki, jak dostrajanie wielkości okna projektu? Sam dotychczas myślałem, że jest to jedynie możliwe za pomocą myszki, ale da się też z klawiatury! To kolejne moje wielkie odkrycie z tej prezentacji, po którym mi i osobom na sali opadła szczęka. Chcąc przykładowo zmienić rozmiar widoku projektu, musimy mieć na nim focus (Alt + 1) i teraz już wciskamy tylko Ctrl + Shift + Prawo / Lewo. Okno z wynikami testu? Po porostu Alt + 4 aby uzyskać fokus i Ctrl + Shift + Góra / Dół. Na oknie z kodem to nie działa, gdyż te skróty odpowiadają za zaznaczanie tekstu i przenoszenie linii w pionie.

Było jeszcze o mulitikursorze, który swoim zasięgiem może objąć wiele wierszy. Tu już trzeba zrobić z użyciem prawego Alt’a i myszki. Ale Idea proponuje jeszcze  coś innego, a mianowicie Alt + J, które zaznacza dany tekst w pliku i tworzy multikursor. Jest jeszcze: Ctrl + Alt + Shift + J, ale jak to działa, sprawdźcie sami. Aby opuścić ten tryb edycji, trzeba wcisnąć 2 x Esc.

Warto przypomnieć o Live Templates (Ctrl + J) i Postfix templates, o których to się nie pamięta, a za pomocą których można tworzyć kod w ciekawszy sposób. Możemy również otaczać kawałek kodu różnymi konstrukcjami (np. if, try/catch, itp.) za pomocą Ctrl + Alt + T.

Warto także utworzyć własną szybka listę (Quick Lists w Settings), gdzie można wrzucić operacje, które często używamy i przypisać wywołaniu tej listy jakiś skrót klawiaturowy. Muszę sobie przygotować taką listę, z rzeczami które często potrzebuję, a nie mają domyślnego skrótu klawiaturowego.

Na koniec jeszcze pozostaje nam Ctrl + ~, które to umożliwia nam szybką zmianę, m.in. kolorów, Look and Feel jak i skrótów klawiaturowych (przykładowo na te z Eclipse’a). Może się to przydać, gdy akurat musimy zrobić Pair Programing z użytkownikiem Eclipse’a. I aby śledzić nasze postępy w niewykorzystywaniu myszki, warto się przyjrzeć statystykom z menu Help -> Productivity Guide.

A Ty jakie znasz bardziej zaawansowane i skomplikowane skróty w IntelliJ Idea? Pisz w komentarzu!

wtorek, 2 lipca 2013

I hate Eclipse

Nienawidzę Eclipse’a. Jest to narzędzie, do którego używania jestem zmuszany, a które w swoim rozwoju się gdzieś tam dawno temu zatrzymało. Niby można w nim znaleźć to samo co oferuje konkurencja, czyli IntelliJ Idea, ale diabeł tkwi w szczegółach, które poniżej przedstawiam. Niby autorzy obydwu środowisk przeczytali  zapewne książkę Martina Fowlera Refactoring: Improving the Design of Existing Code, ale nie wszyscy wykonali robotę tak jak trzeba.

Zaznaczam jednocześnie, że spędziłem sporo czasu na poznanie obu tych środowisk, co wcale nie oznacza, że znam je na wylot. Jak by się więc coś nie zgadzało w opisywanych przypadkach, to proszę o sprostowanie w komentarzu.

Podpowiedzi w kodzie

W Idei mamy tak:



wciskam Alt + Enter i mam:



Czyli zaimportowało mi żądaną kolekcję (a dokładniej interfejs kolekcji), który może być parametryzowany. A więc dokładnie to co chciałem i to jest najczęściej oczekiwane przez 99% developerów.
W Eclipse, chcąc zrobić to samo, otrzymuję długaśną listę, która ma mi niby pomóc:



Na co mi java.awt.List? I to na pierwszej pozycji? Przecież ona nie działa z typami generycznymi, więc powinno być jasne, że to się nie będzie kompilować. A skorzystał ktoś z was kiedyś z którejś opcji od 5 w dół? Idea widząc ten sam kod, patrzy nie tylko na nazwę klasy, ale i na to czy występują ostre nawiasy. Przecież generyki mamy w Javie od połowy 2004 roku.

Zgadywanie typów

Tworząc kod z wykorzystaniem TDD, często najpierw wybieram nazwę dla zmiennej, wywołuję jakąś metodę na niej, a na koniec się zastanawiam, czy powinna to być zmienna lokalna czy pole w klasie i jaki de facto powinien być zadeklarowany typ. W Idei robi się to bardzo przyjemnie (Alt + Enter):



i po wybraniu pierwszej opcji:


Idea proponuje mi, co będzie pasowało, skoro na danym obiekcie chcę wywołać metodę put(). W tym przypadku chcę mieć mapę i takowa podpowiedź jest dostępna.
A w Eclipse:



i po wybraniu drugiej opcji muszę sam przeskoczyć do nowo utworzonej definicji. Miało by to sens, gdyby tworzona automatycznie definicja dała się skompilować. Przeskakuję:


ale brak tu jakiejś sensownej podpowiedzi:


ReformatSettings to klasa, w której wklejałem ten kod, a więc zero pomocy ze strony środowiska.

Tworzenie instancji nowych obiektów

W Idei mamy Ctrl + Space:



i widzimy to co pasuje do interfejsu zadeklarowanego po lewej stronie znaku równości. Na pierwszej pozycji najczęściej wybierana opcja, na drugiej pozycji goły interfejs. Dalej jakieś inne możliwe implementacje.
Analogicznie w Eclipse:


A tu bieda aż piszczy. Nawet jak spróbujemy podpowiedzieć Eclipse’owi co ma zrobić, to i tak mu nie wychodzi:


W powyższym przykładzie próbuję utworzyć instancję klasy implementującej interfejs Map. Wpisuję HM, wciskam Ctrl + Space spodziewając się podpowiedzi, aby utworzyć HashMap’ę. Co dostaję? Jakieś HMACParameterSpec – klasa której nigdy nigdzie nie użyłem, nie wiem do czego służy i (najgorsze) która nie implementuje interfejsu Map.
A jak sprawa wygląda w Idei:


Jako podpowiedź dostaję jedyną słuszną klasę jaka w tym kontekście pasuje do zadeklarowanego interfejsu.

Dopasowywanie podpowiedzi do kodu

Na ten przykład natrafiłem tworząc jeden z postów: Logowanie interakcji w Mockito i jak się trochę nad tym zastanowiłem, że takie kodowanie to czysta przyjemność.

Na początek Idea. Mamy taki oto stan i piszemy właśnie konfigurację mocka:


Tutaj akurat zwykłe Ctrl + Space jakoś szczególnie nie zachwyca (jak to się mówi dupy nie urywa). Ale zobaczmy co się dzieje gdy wciskamy Ctrl + Shift + Space (Smart type).


I tutaj już Idea widzi, co można dopasować. Jako że metoda createUser() jako argumenty przyjmuje login i password, to pierwszą preferowaną opcja jest tutaj wcześniej utworzona stała LOGIN. Co ciekawsze to nie ma na liście analogicznej stałej, ale o nazwie PASSWORD, a która teoretycznie na podstawie typu pasuje! Czyż nie jest to powalające? Mamy również poniżej kilka ciekawych metod, które zwracają String’a jako rezultat, który może nam tutaj ewentualnie podpasować i metodę any() z Mockito! Skąd Idea wie, że jeśli się zabawiamy z Mockami, to w tym miejscu możemy (i ma to sens) wywołać tą metodę?

Idźmy dalej. Zatwierdzamy pierwszą propozycję (LOGIN) Enterem i ponownie naciskamy Ctrl + Shift + Space:



I znów analogiczna podpowiedź. Wybieramy pierwszą, właściwą opcję i Enter. Dopisujemy jeszcze co ma się stać po wywołaniu tej metody, czyli:



I teraz tak:
Ctrl + Shift + Space
Ctrl + Shift + Space
Enter
Ctrl + Shift + Space
Enter
Ctrl + Shift + Enter

I mamy wszystko czego nam do szczęścia potrzeba, razem ze średnikiem na końcu linii.



A w Eclipse:



Jedynie nazwy i typy argumentów. Na dalszym miejscu jest trochę lepiej, przy okazji new:



Po naciśnięciu Ctrl + Space:



mamy jakąś konkretną podpowiedź. Później jest już trochę lepiej:


Ale nadal nie jest to co w Idei.

Dopasowywanie argumentów metod

Kolejna sprawa z podpowiadaniem. Często jako argument metody pasuje tylko jeden typ (np. Enum). W przypadku podpowiedzi Eclipse’a jest trochę ubogo:



Dostajemy tylko nazwy argumentów. Trochę lepiej sprawa ma się gdy zaczniemy pisać nazwę oczekiwanego Enuma:



Tylko na co mi te wszystkie klasy od drugiej w dół? Przecież one w ogóle tu nie pasują. Mój argument jest prostym typem wyliczeniowym, który sam zdefiniowałem, który po niczym nie dziedziczy i nikt po nim nie dziedziczy, bo się nie da. Jest to niepotrzebne zaciemnianie ekranu.

Analogicznie w Idei, przy Ctrl + Space mamy coś takiego:



czyli możemy tą wartość wyczarować z obiektów które mamy (args, export), lub z Enuma. Jeśli chcemy podać konkretną wartość, to lepiej w tym wypadku skorzystać z Ctrl + Shift + Space:



i tu już mamy to co na pewno do sygnatury metody będzie pasować w bardziej zwięzłej formie. A jeśli nie pamiętamy tego skrótu klawiszowego (lub nie pamiętamy dokładnego znaczenia), to zawsze można napisać pierwszą literę potrzebnego Enuma i skorzystać ze standardowego Ctrl + Space:



I wtedy pasujące konkretne wartości typu wyliczeniowego zostaną dopasowane do otoczenia.

Uzupełnianie metod zależnie od kontekstu

Często mi się zdarza, że muszę zmienić nazwę metody, gdy mam już porządnie przygotowaną listę argumentów. Oczywiście w Eclipse działa to tragicznie. Przykładowo mamy taką sytuację:


Argumenty metody są już dobrze dopasowane, ale z jakiś względów początkowo źle wybrałem nazwę asercji. Zaczynam pisać poprawną nazwę metody, potem Ctrl + Space:



i dostaję podpowiedź w postaci różnych wariantów oczekiwanej metody. Wybieram pierwszą podpowiedź z brzegu:


i muszę od nowa uzupełniać listę argumentów. Bezsens!

Jak to działa w Idei? Po naciśnięciu Ctrl + Space również dostaję listę pasujących metod:


Wybieram pierwszą:


i wszystko się od razu dopasowuje do kontekstu.

Skróty klawiszowe

Skróty klawiszowe, to trochę delikatna sprawa. Jednym pasują te z Idei, innym te z Eclipse’a. Najczęściej zależy to od tego, których się wcześniej nauczyliśmy i jak bardzo się do nich przyzwyczailiśmy. A przyzwyczajenia to zło. Uznajemy czasem, że skróty są narzucone z góry i są logicznie poukładane. Czy na pewno?

Ctrl + D w Eclipse to usunięcie linii (delete), a w Idei skopiowanie w dół (duplicate). Jest to dla mnie największa bolączka, gdy się przesiadam z jednego środowiska do drugiego, gdyż jest to pierwsza różnica, która mi doskwiera. Do usuwania linii w Idei służy Ctrl + Y, co swoje korzenie ma w edytorze Vim (Yank – yy – usuwa aktualną linię). Ponadto Alt + F7 (wyszukiwanie użyć) i Shift + F6 (zmiana nazwy) mają swoje korzenie z Total Comander'a.

Kolejna sprawa (moja ulubiona), to te genialne czteroklawiszowe skróty w Eclipse, na których można się dorobić trwałego kalectwa palców: Alt + Shift + X, T – wystartowanie testów, lub czegoś innego w zależnie od ostatniej naciśniętej litery. Tą czynność wykonujemy bardzo często w cyklu TDD, więc ten hotkey powinien być łatwiejszy. Jak się doinstaluje MoreUnit, to jest trochę lepiej, ale jak pokazuję ten skrót niektórym kolegom (zwłaszcza tym starszym, którzy etap nauki i rozwoju mają już dawno za sobą), to wymiękają w tym momencie, twierdząc, że taka gimnastyka to dla nich za dużo. Dodatkowo tą ostatnią literę trzeba wcisnąć nie za szybko i nie za późno.

Kolejny super skrót to np. Alt + Shift + Q, C – przeskoczenie do konsoli. Można również przeskoczyć do innych widoków... Tylko co z tego, skoro aby wrócić do edycji kodu należy kliknąć myszką, lub Ctrl + F7? Skrajna ułomność i niedopatrzenie.

W Idei mamy problem przeskakiwania pomiędzy widokami o wiele lepiej rozwiązany. Do tego używamy Alt + numer widoku. A numery widoku mamy zazwyczaj widoczne na ekranie:


Są to te numerki tuż przy nazwie widoku. Dodatkowo, jak chcemy wrócić już do okna edycji to wciskamy po prostu Esc. Czyż to nie jest intuicyjne? A jak nam to okienko przeszkadza, to można wcisnąć Shift + Esc i je zamknąć, równocześnie przeskakując do okna edycji kodu. Można też ponownie skorzystać z kombinacji przeskakującej do aktualnego widoku (Alt + numer), która przy drugim naciśnięciu zamyka dany widok.

I tu wychodzi kolejna wyższość Idei nad Eclipsem. W Eclipsie mamy koncepcję perspektyw: Java, JavaEE, Debug itd. Jak się pomiędzy nimi przełączamy, to pewne widoki (views) znikają a inne się pojawiają, a jeszcze inne są trochę zdeformowane i na innych pozycjach. W Idei odpowiedniki Eclipsowych widoków pojawiają się i znikają „na żądanie”. Oczywiście wszystko sterowane z klawiatury.

Wracając do skrótów klawiaturowych. W Eclipse brakuje sporo ważnych skrótów, aby były od razu po instalacji dostępne. I tak bardzo często korzystam w Idei ze skakania od razu do implementacji (Ctrl + Alt + B). W Eclipse trzeba sobie samemu taki skrót podlinkować, np. Alt + F3, aby nie wiele się różnił od typowego skakania do deklaracji. Niestety nie wielu developerów wie o tej możliwości.

Przypisywanie wartości do pól, zmiennych lokalnych, stałych

W Eclipse mamy tzw. Quick Assist (Ctrl + 2), czyli przypisywanie do pola / zmiennej lokalnej, które działa bardzo kiepsko. Przykładowo w Eclipse dla takiego kodu:


nic nie da się zrobić, gdy kursor jest na końcu linii. Zresztą jak się zaznaczy kod od słówka new do końca linii to i tak Eclipse nic z tym nie wymyśli. Alt + Shift + L (Extract Local Variable) też nic nie pomoże. Idea natomiast radzi sobie z tym wyśmienicie:

Ctrl + Alt + V (Value):


Ctrl + Alt + F (Field)


Tutaj dodatkowo Idea sprawdza, czy to samo wyrażenie nie występuje jeszcze gdzieś w kodzie i sugeruje jego zastąpienie. Oczywiście z pomocą Alt + A można to zrobić bez konieczności użycia myszki.

Ctrl + Alt + C (Constans)


Tutaj dodatkowo Idea zapisuje stałą wielkimi literami, jak to się powszechnie w Javie przyjęło. Oczywiście wszystkie te refaktoringi można cofnąć za pomocą Esc lub Ctrl + Z. A jak w Eclipse wyeksportować do stałej? Mamy kolejnego łamańca: Alt + Shift + T, A, które i tak w przykładowym kontekście nie zadziała i do którego nie ma przypisanego standardowego skrótu.

Eclipse również sobie nie radzi jak ma trochę bardziej skomplikowane wyrażenie, którego wynik chcemy zapamiętać w zmiennej lokalnej. Przykładowo:


Nie działa ani Ctrl + 1, Ctrl + 2, ani Alt + Shift + L. Bieda! A w Idei Ctrl + Alt + V zachowuje się zgodnie z oczekiwaniem:


Idea pozwala nam zadeklarować pole jako final, zmienić przy tej okazji typ zmiennej, jak i sam dorzuca średnik na końcu.

Zaznaczanie tekstu

W Idei jest jeszcze cos takiego jak Ctrl + W (Incremental expression selection). W Eclipse jest niby coś analogicznego: Alt + Shift + Up, ale nie działa to tak fajnie jak w Idei.

Przesuwanie kodu w pionie

Kolejnym skrótem, którego mi bardzo brakuje w Eclipse jest inteligentne przesuwanie kodu Ctrl + Shift Up/Down (Move Statement Up). W Eclipse brak ekwiwalentnego skrótu, a działa on tak:

Przed:


Po:


Czyli po naciśnięciu Ctrl + Shift + Up cała metoda setName() została przeniesiona powyżej getName(), czyli tam gdzie ma ona sens. Jest to bardzo przydatna funkcjonalność podczas refaktoringu.

Komentowanie

Jeszcze irytująca mnie rzecz, to działanie Ctrl + / w Eclipse. Skrót ten wstawia komentarz w aktualnie zaznaczonych liniach, ale działa tylko w Javie. W przypadku plików XML, HTML i innych należy używać  kolejnego, ale działającego wszędzie łamańca: Ctrl + Shift + C, zamiast prostego Ctrl + /. W Idei ten ostatni skrót działa wszędzie i wstawia komentarz zależnie od kontekstu w jakim się znajdujemy.

Refactoring

W Idei gdy zmieniamy nazwę pola w klasie (Shift + F6), które to posiada gettery i settery, to dostajemy zapytanie, czy te metody dostępowe również przeorać:


Dodatkowo Idea sugeruje, aby dopasować nazwę parametru w konstruktorze do nowej nazwy pola:


wciskamy spację, lub Alt + A aby wybrać wszystkie sugestie i Ctrl + Enter aby zamknąć okno. Następnie Idea jeszcze sugeruję nazwę pola, która jest użyta jako tekst w metodzie toString():


Oczywiście akceptujemy to za pomocą Alt + D i gotowe! Wszystko co chcieliśmy zostało dopasowane.

A w Eclipse? Eclipse zmienia tylko nazwę pola. Musimy sami pamiętać o getterach / setterach, konstruktorach i tekstach w toString(). Czyli mamy jakieś plus 4 więcej kroków do wykonania!

W Idei również działa całkiem dobrze (albo właściwie nie wiele gorzej) refaktoring, gdy go wykonujemy, gdy nasz kod się nie kompiluje. Dla Eclipse’a jest to najczęściej nie do wykonania.

Usability

Standardowo w Eclipse jest sporo ukrytych funkcjonalności. Czyli jeśli nie przeczytasz setki tutoriali, lub jeśli nie przeklikasz każdej opcji z okna Preferences, to będziesz mógł sobie tylko żyły wypruwać. I tak podczas Legacy Code Retreat, miałem spory problem z głupim wklejeniem tekstu wielolinijkowego do edytora tak, aby był traktowany jako String. Praktyczny przykład poniżej:


W Eclipse funkcjonuje to tak:


Czyli istna tragedia. Razem z osobą, z którą aktualnie byłem sparowany, straciliśmy z 10 minut, na doprowadzenie tego do stanu używalności, za pomocą metody find & replace. W Idei jest to out of the box:


Później jeszcze poszukałem chwilkę w necie i znalazłem rozwiązanie na to:


Źródło: http://stackoverflow.com/questions/2159678/paste-a-multi-line-java-string-in-eclipse

Inne, ogólne

Kolejny wielki błąd w designie Eclipsa to brak ciągłej synchronizacji pomiędzy tym co jest w edytorze a stanem na dysku twardym. Wystarczy czasem zrobić builda z zewnątrz lub jakiegoś update’a z repozytorium i podczas próby otwarcia pliku otrzymujemy coś podobnego do tego widoku:


Jeszcze jestem w stanie zrozumieć, że Eclipse nie odświeża sobie wszystkich plików ze wszystkich otwartych projektów (choć w Idei to działa dobrze i szybko), ale w momencie próby otworzenia pliku mógłby sobie już sam automatycznie to odświeżyć, zamiast wypisywać out of sync.

Dodatkowo jakość pluginów Eclipsowych jest bardzo słaba. Są one rozwijane po za podstawowym środowiskiem, czyli czasem działają, czasem nie, a po jakimś czasie autorzy często zarzucają jego rozwój. Tak się np. stało z MouseFeed, który przez długi czas nie działał z Eclipsem 4.X. Na szczęście plugin został ostatnio reaktywowany: Eclipse Mousefeed Plugin Merged With Marketplace Plugin. W przypadku innych pluginów nie wszystko zawsze dobrze działa. W Idei natomiast rozwój pluginów jest wspierany przez samych twórców, którzy dostarczają odpowiednią ich jakość i ich niezawodność.

Kilka dni temu (tj. 26 czerwca 2013) opublikowano nową wersję Eclipse'a 4.3 Kepler. Jeszcze jej nie sprawdzałem, ale pewnie nie wiele się zmieniło. Zrobię to pewnie za jakiś czas, jak już pluginy dostosują.

To chyba by było na tyle, choć jak by się chciało, to by się jeszcze znalazło parę Eclipse’owych niedogodności, ale wtedy nigdy bym nie opublikował tego posta. Następnym razem jak ktoś się mnie zapyta, „a co takiego ma Idea, czego nie ma Eclipse?” to go po prostu odeślę do tego artykułu.

A ty które wybierasz?