Devoxx w Polsce - wrażenia z pierwszej edycji

Pierwszy Devoxx w Polsce (dawniej 33 Degree) odbył się w dniach 22-24 czerwca 2015, w nowo wybudowanym centrum kongresowym w Krakowie, mogącym pomieścić ponad 2000 ludzi. I to było idealne miejsce na konferencję - nowy, ładny i przestronny budynek z ogromną salą z balkonami na trzech poziomach, gdzie mogli zmieścić się wszyscy uczestnicy.

Konferencję otworzył standardowo Grzesiek Duda. W trakcie rozpoczęcia miała być krótka prezentacja Vaadin Designer’a, ale niestety był problem z połączeniem laptopa do rzutnika. Z racji ograniczonego czasu, trzeba było uwierzyć na słowo, że narzędzie jest fajne.

Pierwszy keynote poprowadził Hadi Hariri: "The Silver Bullet Syndrome". Opowiadał o tym, w jaki sposób szukamy rozwiązania starych problemów, czyli o wynajdowaniu koła na nowo, aby było bardziej okrągłe. I tak z make’a przerzuciliśmy się na ant’a, później maven’a i gradle’a… Poszukujemy idealnego rozwiązania, najlepiej naszych wszystkich problemów, czyli tytułowego silver bullet. Powoduje to następujący "cykl przetrwania w IT": nowa technologia -> wciśnięcie jej użytkownikom -> organizowanie szkoleń -> użycie na produkcji -> jak coś nie działa, to telefon do konsultanta i tak w kółko od nowa.

Hadi wyśmiewał jeszcze inne potworki jakie tworzymy, np.: AbstractSingletonProxyFactoryBean, FizzBuzzEnterpriseEdition i JavaScript:

Tak naprawdę, to powinniśmy zadać sobie pytanie, jaką to nam przyniosło wartość biznesową? Jak usprawniliśmy czyjąś pracę lub życie, a nie wymyślamy kolejne frameworki. Nasze CV powinno więc wyglądać raczej tak:

(Sorry za kiepską jakość...) 

Ostatecznie stanęło na tym, że jednak musimy ciągle uczyć się nowych rzeczy. Nagranie z prezentacji (ale nie z Devoxxa) jest dostępne na Vimeo: https://vimeo.com/130202574, a starszą wersję slajdów znalazłem tutaj: http://schd.ws/hosted_files/buildstuff14/a5/wcf.pdf

Pierwszą prezentacją po keynote na którą poszedłem było: "Principles Of Microservices", Sama Newmana. Było o The Twelve Factors, czyli o zebranych zasadach z doświadczeń, jak pisać aplikacje, które są deploy'owane w dużych ilościach, aby było łatwiej nimi zarządzać i utrzymywać.

Z rozwiązań, które warto zapisać (i może kiedyś im się w razie konieczności lub nadmiaru wolnego czasu przyjrzeć) to:

• Pact - biblioteka do testowania i definiowania kontraktów pomiędzy mikroserwisami (czyli: Consumer driven contracts) 
• ZooKeeper - do ogarnięcia utrzymania, konfiguracji itp. wielu rozproszonych systemów 
• etcd - rozproszona konfiguracja dla wielu serwisów 
• Consul - to samo (albo prawie to samo co dwa powyższe)

Sam na prezentacji przedstawił 8 zasad mikroserwisów i je wyjaśnił:

• Modelled Around Business Domain 
• Culture Of Automation 
• Hide Implementation Details 
• Decentralise All The Things 
• Deploy Independently 
• Consumer First 
• Isolate Failure 
• Highly Observable 

Najbardziej mi utkwiło w pamięci, że trzeba mieć jedną osobę, która patrzy na aplikację i co się w niej dzieje, korzysta z kibany i stosując correlation id, śledzi, co dokładnie się dzieje z danym request’em i gdzie najwięcej czasu spędza. A tutaj jakaś starsza wersja slajdów z XP Days Ukraine

Następnie pospieszyłem na "OnConnectionLost: The life of an offline web application", prowadzoną przez młodych pracowników z ThoughtWorks: Stefanie Grewenig i Johannesa Thönesa. Prelegenci tworzyli aplikacje, które musiały działać w przeglądarce i również off-line. Przykładowo aplikacja na tableta dla pracownika supermarketu, który sprawdza dostępność produktów na półkach i zamawia co trzeba. Dawniej korzystano z kartek do tego celu, ale można pójść z duchem czasu i zrobić to lepiej. Połączenie z internetem bardzo łatwo zgubić na sklepie, a zamówienie trzeba złożyć, więc warto w takim przypadku, aby aplikacja działała offline.

I tak za pomocą html5 application cache możemy zdefiniować, które zasoby powinny zostać zapamiętane po stronie przeglądarki, do działania w trybie offline. Mamy również możliwość, wymuszenia aktualizacji tych zasobów, gdy pojawią się ich nowsze wersje na serwerze. Najważniejsze, aby manifest, w którym definiujemy co ma być cachowane, sam nie został zcache'owany. W tym celu warto ustawić w nagłówkach no chache. Alternatywą dla application cache jest Service Workers, ale póki co jest to googlowy wynalazek, zaimplementowany tylko w Chromie i FF.

Jeśli chodzi o przechowywanie wprowadzonych danych offline, to mamy Web Storage i IndexedDB. W pierwszym rozwiązaniu jest sporo problemów (między innymi jak użytkownik chce otworzyć wiele zakładek naszej aplikacji) i prelegenci zalecali drugie rozwiązanie. Oferuje ono transakcyjność pomiędzy wieloma zakładkami. Niestety obecnie jest ono wspierane tylko w Chrome.

Ostatnim problemem, jaki jest do rozwiązania przy aplikacjach działających w przeglądarkach off-line, to synchronizacja danych. Warto korzystać od samego początku ze wzorca Command, czyli wszelkie zmiany, jakie wykonuje użytkownik wrzucamy do lokalnej kolejki i jak stanie się online, to je dopiero przetwarzamy na serwerze. Ewentualnie, aby nie mieć jakiś problemów z łączeniem wyników, to możemy zapisać snapshot’a aktualnego wyniku. Nie warto się spalać nad rozwiązywaniem konfliktów (o ile nie piszemy gita przez przeglądarkę), a w najgorszym wypadku możemy wyświetlić dwie wersje dokumentu i użytkownik skopiuje sobie to, co mu brakuje do nowszej wersji.

Z dalszych rad - danych wrażliwych nie powinniśmy zapisywać w przeglądarce, bo są one dostępne jawnym tekstem, a sama enkrypcja po stronie JavaScriptu może nie być najlepsza. I jeżeli decydujemy się na budowanie aplikacji działającej bez połączenia z internetami, to w pierwszej kolejności powinniśmy zadbać o działanie bez serwera i wprowadzenie wzorca Command zamiast requestów. W innym wypadku bardzo zemści się to na nas w późniejszym czasie. Slajdy można obejrzeć tutaj: http://www.slideshare.net/jthoenes/onconnectionlost-the-life-of-an-offline-web-application-craft-conf-2015

Kolejne wystąpienie pt.: "Co było pierwsze: kod czy architektura?" Sławka Sobótki rozpoczęło się od poziomów cywilizacji wg. Skali Kardaszewa, aby zachęcić słuchaczy do aktywnego słuchania. I to się z pewnością Sławkowi udało. Prelegent „zajrzał” na chwilę do umysłu programisty i architekta. Ten pierwszy w przypadku problemu wyboru rozwiązania A i B próbuje wybrać lepsze. Architekt w takim przypadku robi krok wstecz, patrzy z dalszej perspektywy i zastanawia się, czemu w ogóle mamy wybór i czy rzeczywiście musimy wybierać.

Następnie przyglądaliśmy się różnym rodzajom obrazków, jakie malują architekci, aby przejść do tego, jak je malować. Dobry podział tych obrazków jest zebrany w książce Software Architecture for Developers, a mianowicie C4:

• Context - czyli architektura korporacyjna. Pokazujemy na niej osoby korzystające z systemu, inne zależne systemy i instytucje. Odbiorcami taki obrazów są klienci i zarząd. 
• Containers - architektura wdrożenia. Tutaj mamy wszelkie techniczne zależne elementy, jak bazy danych, kolejki komunikatów, repozytoria, bazy danych, kontenery, klienci (w sensie przeglądarka, aplikacja na telefon). Jest to przydatny diagram dla administratorów, utrzymaniowców i DevOpsów. 
• Components - czyli architektura systemu. Obrazek ten pokazuje komponenty / moduły (jakkolwiek sobie zdefiniujemy czym to dokładnie jest). Jest to przydatne dla programistów, dając obraz z lotu ptaka na aplikację 
• Classes - architektura aplikacji, pokazująca wewnętrzną strukturę dokumentu, bardziej wzorce niż konkretne klasy 

Jak prezentacja Sławka będzie dostępna on-line to umieszczę tutaj odpowiednie zdjęcia.

Z praktycznych rzeczy to zapamiętałem (albo raczej sobie zapisałem) jeszcze parę rad. Jeśli korzystamy z RESTa, to powinniśmy mieć teoretycznie tylko nazwy zasobów w adresach URL. Jednak praktycznie, to warto rozważyć, co częściej się nam zmienia: zasoby czy procesy? Gdy zasoby są w systemie stabilne, to robimy RESTfull, a jak procesy to do RESTa wrzucamy czasowniki.

Connascence oznacza, że jak coś zmieniamy w jednym miejscu w systemie, to musimy to również zmienić w drugim miejscu. Przykładowo mikroserwisy nie powinny korzystać z bibliotek współdzielonych. I dodatkowo powinniśmy rozdzielać pojęcia w systemie, aby lepiej nam się rozdzielało komponenty systemu.

W ten sposób zostało przedstawione, jak tworzenie dużej architektury od początku prowadzi do kodu. Następnie Sławek spróbował pokazać podejście odwrotne, tzn. jak z naszych mikrodecyzji na poziomie kodu wyłania się nasza architektura.

Podsumowując, nie wiadomo który framework jest lepszy, ani który język programowania. Programowanie to dyscyplina polegająca na zmyślaniu - faktura to funkcja, albo faktura to obiekt… A tak to wszyscy powinniśmy się nauczyć assemblera, aby wiedzieć jak działa krzem, aby przestać toczyć wojny religijne, o to który język programowania jest lepszy...

Następnie byłem chwilę na wykładzie "Using JavaScript/HTML5 Rich Clients with Java EE 7", Reza Rahmana, ale musiałem wyjść. W sumie dobrze, bo z późniejszych opinii było nieciekawie, głównie historia, jak to przez lata próbowano ożenić frontend z backendem.

Poszedłem więc na: "Technical leadership – from an expert to a leader", Mariusza Sieraczkiewicza. Nie widziałem początku, ale prelegent mówił o tym, że dobry leader powinien przygotować takie środowisko, że każdy będzie chciał w nim pracować. Następnie było o rzeczach, których każdy powinien spróbować: więcej myśleć niż tylko reagować, robić sobie codzienną retrospektywę, zrozumieć, a nie oceniać - coaching. Aby móc lepiej motywować ludzi, to powinniśmy ich lepiej poznać, jakie są ich potrzeby i zbierać feedback, a w Agile jest pełno narzędzi związanych z feedbackiem.

Na koniec Mariusz ogłosił, że pisze książkę na ten temat i szuka chętnych chcących podzielić się z nim swoimi doświadczeniami. Kontakt można znaleźć na jego blogu: http://msieraczkiewicz.blogspot.com/

Przedostatnią prezentacją pierwszego dnia konferencji była: "Caching reboot: javax.cache & Ehcache 3" prowadzona przez Louis Jacomet. Początkowo prowadzący omówił, co ile czasu zabiera, jak przeskalujemy czas pewnych operacji komputera na bardziej ludzkie, odczuwalne i zrozumiałe jednostki. Miało to na celu uświadomienie sobie, że naprawdę potrzebujemy cache w aplikacji. Następnie było o zmianach w EhCache w wersji 3 w stosunku do wersji 2. Mianowicie Java doczekała się ustandaryzowanego Caching API ujawniającego się pod numerem JSR-107. I nowa wersja EhCache’a implementuje tą specyfikację, przez co wsteczna kompatybilność została złamana.

W standardzie JSR-107 nie ma zdefiniowanych ustawień dla Capacity control, ani Locking Options. Dalej było demo, jak łatwo można korzystać z EhCache. Jest możliwość modyfikowania ustawień w trakcie działania aplikacji. Problemem jest jedynie odpowiednia konfiguracja, a mianowicie dobranie odpowiednich wartości. Jedyne co prowadzący mógł polecić, to pójście na produkcję i obserwowanie zachowania. Największym wyzwaniem przy implementacji EhCache’a jest założenie, że błąd w cache’u nie powinien skutkować wyjątkiem do użytkownika (aplikacji). Prezentacja całkiem fajna.

Na końcu dnia poszedłem na prezentację Adama Warskiego pt. "Supler: complex web forms, not so complex". Adam jak zwykle w wielkim stylu przedstawił rozwiązanie, które stworzył wraz z zespołem w SoftwareMill’u. Supler jest narzędziem, które spaja frontend w JavaScripcie z backendem Scalowym. Pomaga generować formularze (nawet zagnieżdżone i skomplikowane), a jednocześnie nie jest związany z żadnym frameworkiem. Było przez cały czas live demo i niewiele slajdów. Trochę mi umknęło jak ożenić to rozwiązanie z jakimś frejmworkiem JS. Gdybym musiał tworzyć formularze w Scali, to z pewnością bym pozytywnie rozważył użycie Suplera w projekcie.

Podsumowując pierwszy dzień konferencji, to trzymał poziom, ale czegoś mi zabrakło. Początkowy wykład był mocno motywujący i dający do myślenia, Sławek Sobótka bardzo fajnie opowiedział o malowaniu architektury, ale to było bardzo miękkie. O EhCache i Suplerze była całkiem niezła, ale tego drugiego raczej nie będę mógł zastosować praktycznie w najbliższym czasie. Zabrakło mi trochę jakiejś mocno technicznej prezentacji na temat czegoś nowego, świeżego, lub wywracającego myślenie do góry nogami.

Voxxed Days Vienna 15

Ledwo zakończył się ChamberConf, a tu już czas na Voxxed Days Vienna 15. Była to moja pierwsza zagraniczna konferencja, nie licząc Code Retreatów. Wejściówkę wygrałem w losowaniu, więc czemu by nie pojechać? W końcu z Wrocławia do Wiednia jedzie się tak długo, jak jeszcze całkiem niedawno jechało się do Warszawy.

Konferencję otworzył Greg Young z tematem Polyglot Data. Była to powtórka z Wrocławia, między innymi opowieść o programiście, co zbamałucił system obstawiania wyścigów konnych i jak można było się przed tym zabezpieczyć.

Następnie byłem na prezentacji Norberto Leite - ewangelisty z MongoDB - pt. Operational Database with Elephant Memory. Początkowo było dużo marketingowego gadania, jak to CTO, CIO, CSO i inni C* widzą bazy danych. Było bardzo dużo odniesień do wcześniejszego wystąpienia Greg'a, który trochę jechał po Mongo DB. Według Norberto, ssie ta baza danych, którą akurat używamy.

Dalej były podstawy Hadoopa (HDFS, YARN, MapReduce) oraz o Pig, Hive, Sparku, jakie są drivery do Mongo, z czym można się integrować... Miało być demo, ale nic konkretnego w końcu nie było. Merytorycznie bardzo słabo.

Później byłem chwilę na wystąpieniu Michaela Nitschingera, ale przeniosłem się na Monadic Java prowadzone przez Mario Fusco. I na początek zobaczyłem te wzory

Tak naprawdę, to monady ukrywają if'a w metodzie, dzięki czemu możemy ładniej, funkcyjnie zapisywać nasz kod. Był pokazany przykład, jak można zrobić dzięki monadom walidację obiektów, a za zadanie domowe, Mario zadał, aby napisać system transakcyjny, z wykorzystaniem monad rzecz jasna.

Prelegent jest współorganizatorem Voxxed Days Ticino. Zastanawialiśmy się w przerwie gdzie to jest (Google Maps lokalizowało Ticino w Szwajcarii i we Włoszech), ale w końcu okazało się, że chodzi o włoski region w Szwajcarii. 

Później był obiad i tu spore zaskoczenie. Część jedzenia przyjechała z Polski.

W końcu Grzesiek Duda był organizatorem tej konferencji i pewnie wychodziło taniej w ten sposób. Część napoi też przebyła sporą drogę.

Kolejny slot był słaby, odwiedziłem wszystkie sale, ale nic ciekawego nie znalazłem.

Później była druga prezentacja Grega Younga, który w zastępstwie kontynuował poranny wykład. Było m.in. o tym aby nie ufać benchmarkom, że często dane z nich przekraczają fizyczne możliwości urządzeń.

Kolejna prezentacja była Sergeya Kuksenko, który to na co dzień pracuje w Oracle i zajmuje się performance'm Javy. Mimo developerskiego charakteru jego pracy, musiał oczywiście pojawić się disclaimer na początku. 

Wykład było mało praktyczny, ale bardzo ciekawy. Było o wydajności Javy, ale na poziomie procesora. Sporo rzeczy przypomniało mi się z architektury komputerów ze studiów. Kod z przykładów jest dostępny tutaj: kuksenko/quantum, a slajdy poniżej.

"Quantum" Performance Effects from Sergey Kuksenko

Ostatni wykład był Christophera Bateya o microservisach. Prelegent przedstawiał, jak to on w projekcie zbudował system, będąc świadomym problemów wynikających z rozproszenia aplikacji. Jednak wszelakie przypadki, że część systemu nie działa, albo są lagi na sieci miał przetestowane.

I tak do symulowania problemów z siecią korzystali z saboteur, a do mockowania web serwisów WireMock. Spore streszczenie prezentacji Christophera można znaleźć na jego blogu: Building fault tolerant services: Do you handle timeouts correctly?

Sama prezentacja nie była jakaś fajna, czegoś w niej brakowało...

Na koniec było jeszcze piwo sponsorowane prze TypeSafe. Niestety nie mogłem zostać za długo, ale z tego co wiem, to impreza trwała długo.

Co do samej imprezy, to miała  ona na celu rozruszanie lokalnej społeczności. Merytorycznie daleko jej było do tych najlepszych konferencji - była to typowa lokalna inicjatywa, która jak na pierwszy raz wyszła całkiem spoko.

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!

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.