Sunday 2 December 2012

Java puzzle ;)

    Integer a = 200, b = 200;

    System.out.println(a < b || a == b || a > b);

    System.out.println(a <= b || a > b);



I'm not the type of guy who TYPICALLY likes stuff like that. IMO code used in many java-mind-fucks is just unreal to be found in application written by someone that is not out of his mind ;) But this one posted here I find to be just lovely :)


If you have your own favorites, post them as a comment :)


Ok, but lest focus on above code sample.

Here is short answer and explanation: FALSE and TRUE. True because of both `a` and `b` are damn numbers, so it has to be truth no matter what. And false, because: `a` is NOT lower than `b`; `a` is NOT grater then `b` and `a` and `b` are not pointing to the same Intereger object. Cache size is <-128, 127> - check the Integer javadocs if needed.

But that's not all, things can start being interesting from now on. You can actually make both of those sysouts TRUE! How?

Take a look here:



from java.lang.Integer:
    /**
     * Cache to support the object identity semantics of autoboxing for values between
     * -128 and 127 (inclusive) as required by JLS.
     *
     * The cache is initialized on first usage.  The size of the cache
     * may be controlled by the -XX:AutoBoxCacheMax=<size> option.
     * During VM initialization, java.lang.Integer.IntegerCache.high property
     * may be set and saved in the private system properties in the
     * sun.misc.VM class.
     */

    private static class IntegerCache {
        static final int low = -128;
        static final int high;
        static final Integer cache[];

        static {
            // high value may be configured by property
            int h = 127;
            String integerCacheHighPropValue =
                sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
            if (integerCacheHighPropValue != null) {
                int i = parseInt(integerCacheHighPropValue);
                i = Math.max(i, 127);
                // Maximum array size is Integer.MAX_VALUE
                h = Math.min(i, Integer.MAX_VALUE - (-low));
            }
            high = h;

            cache = new Integer[(high - low) + 1];
            int j = low;
            for(int k = 0; k < cache.length; k++)
                cache[k] = new Integer(j++);
        }

        private IntegerCache() {}
    }



It's like mindfuck inside mindfuck - no1 expects this :)

Anyway, empowered with that knowledge, lets hope it's not useless, but alike to the python paradox. Knowing that little trick does NOT make you a better programmer, but there is a big chance that you ARE already a good programmer if you know about it ;-)

Monday 19 November 2012

Some simple Windows tools that will make you happy

Currently I'm migrating from one PC to the other, so there are couple of things that I HAVE to take there with me:
 

Map Any Key to Any Key on Windows 7 / XP / Vista - can be useful if you have page up and page down keys next to arrows, IMO home / end should be placed there.

Ditto - Clipboard Manager - remembers all CTR+C 's :)

Unlocker

Monday 12 November 2012

Producer-Consumer sample - Listing files

Listing files is reeally slow operation.

That's why I decided that it will be a good use case to have some fun with java's concurrency.

Producer-Consumer pattern seemed to fit my needs.
  1. Producer is listing all files from given directory. 
  2. Consumer is filtering proper files and propagates this data to GUI in real-time. 
  3. Both are connected by BlockingQueue
BlockingQueue<List<File>> myQueue = new LinkedBlockingQueue<List<File>>();

Please find my sources @ https://bitbucket.org/pawelmichalski/repo/src.

... Actually I should write something about my code to justify some of my implementating decisions, but it's being late right now in Poland :) so consider this entry as asking for code review in some free time.


cheers.

Sunday 28 October 2012

CodePro AnalytiX by Google.

Some of my older posts contained my recommendation for The Pragmatic Programmer book. I must say that's a truly awesome book. But it's not for everyone. It's addressed to those who CARE. Care about their work, career, self-development, etc... I'm so amazed by this book, that I'm willing to summarize some of its chapters, but right now I just need to quote single thing:


Now that you have some guidelines on what and when to add to your knowledge portfolio, what's the best way to go about acquiring intellectual capital with which to fund your portfolio? Here are a few suggestions.

Learn at least one new language every year.

Read a technical book each quarter.

Read nontechnical books, too.

Take classes. 


Participate in local user groups. Don't just go and listen, but actively participate. Isolation can be deadly to your career; find out what people are working on outside of your company.


Experiment with different environments.

Stay current. 


Get wired. 


I didn't strip that the-one-and-only point from the comment because it's the one that I find the easiest and most rewarding, yet so often ignored.

I'm proud member of Java User Group Łódź. During the latest prelection, one of the questions asked to presenter has inspired my to find some tool for measuring code metrics... I just wanted to have some fancy tool, that would make me smile and tell me "your code looks great!" ;). So I did what I do in most cases - I went to stackoverflow, and THIS is what I have found.

What made me curious was answer,  that was posted long after question was asked, and yet it has the most up-votes. It was about CodePro AnalytiX by Google - plugin for Eclipse. Wow, that's even more than I was searching for!

Key (at least for me) features:

Metrics: just metrics. Those that seem to be bad, are colored red.



Code Audit: yet another tool like Sonar or findbugs.



JUnit Test Case Generation: This is really cool, try it. How does it work? (from specification):
  1. generates a list of values for the fixture (if the target method is an instance method) and each of the arguments,
  2. determines which combinations of values to use to invoke the method,
  3. computes the result of invoking the method,
  4. figures out how to validate the result, and finally
  5. generates one test method for each combination of values.













Of course in most cases  (sometimes - as on image - it works better) 'tested' is only:
assertNotNull(result);
but even though it works as great stub that can be filled with real testing code.


Similar Code Analysis: Searches for code duplication - works better than WinMerge ;)



There are much more of features that CodePro has to offer, find them by yourself. It's so enjoyable.

One last remark: CodePro has different versions for different Eclipse versions. Latest is 3.7 - for Indigo. But it works good with the new Juno, too - trust me ;)

Thursday 18 October 2012

Opowiastka

Dziś będzie opowiastka, więc będzie po polsku, bo tak łatwiej.

Z okazji zmiany numeru telefonu na fejsbuczku, portal ten zaskoczył mnie czymś, co chyba trzeba potraktować jako rodzaj troski...

Prawda, że to miłe? Ktoś nade mną czuwa!

No dobrze, ale co z tego? No w sumie nic... bo w realnym życiu, a przede wszystkim w realnej pracy, czuwać powinniśmy sami nad sobą. Jak?! Ano oczywiście testami...

Wczoraj, w sumie to całkiem świeżo po przeczytaniu powyżej przytoczonego maila, kumpel w pracy zapytał mnie o kod, w którym jakiś czas temu coś zmieniałem... Od tego czasu minęły ponad 2 tygodnie, a ja zdążyłem zwiedzić 2 projekty, więc mój bufor zdążył się wyczyścić i zapełnić czymś zupełnie innym. Owe "coś" to były zmiany nietrywialne - w sumie bardziej przepisanie niemal od zera części funkcjonalności, niż refaktoring. Pytanie sprowadzało się mniej więcej do: czemu to nie działa?! No i miałem problem... Kod, którzy przerabiałem przez ponad 2 dni, okazał się wadliwy. Można by te zmiany zrevertować, gdyby nie to, że na ich bazie szedł cały późniejszy development i w międzyczasie doszło już pewnie kilka lub kilkanaście commitów kolegów z teamu. Więc najprostszą i w sumie jedyną opcją było wytropienie błędu.

Testów było mało, ale wszystkie przechodziły... Na co więc komu takie testy? teoretycznie psu na budę... ale tylko teoretycznie. Przypomniałem sobie, że ten mój refaktoring też był otestowany, bo inaczej bym się za to w ogóle nie zabierał, bo tyczyło się to problemu, z którego wiedzę domenową mam nadal bardzo nikła, więc moja praca z tym kodem wygląda następująco: ok, kompiluje się, to fajnie... ale czy działa jak należy? - nie mam pojęcia! 

Funkcjonalność, którą miałem przebudować, polegała na tym, że dla danego wejścia do metody, powinno się uzyskać ściśle określone wyjście, które wynikało z wiedzy domenowej. Pierwotnie była to zwykła metoda prywatna, którą trzeba było gruntownie przebudować i przenieść do commonsów, ale efekt miał pozostać taki sam. Zacząłem więc od testu, który mi wypisze (tak, nie użyłem loggera, lecz System.outy!) wszystkie możliwe wyniki działania tej metody. Parę sekund po tym miałem już listę spodziewanych rezultatów, którą mogłem iterować i wewnątrz assertEquals'ów, których liczba rosła wraz z posuwaniem się naprzód wspomnianego przerabiania kodu. (Nawiasem mówiąc, myślę, że jest to podejście, które mógłbym polecić każdemu, kto ma zmieniać coś, o czym ma dość nikłe pojęcie - najpierw solidnie przetestować  pierwotne działanie a dopiero potem poprawiać/psuć kod początkowy.) Na sam koniec kod z commonsów działał dokładnie tak jak ten pierwotny, ale był napisany znacznie lepiej (o czym przekonałem się dziś, kiedy musiałem dołożyć nową funkcjonalność).

Wszystko ładnie pięknie - były testy, kod udawał, że działał. Stało się tak, dlatego, że testowałem kod z commonsów w oderwaniu od kodu, który go używał. Musiałbym powiększyć zakres moich początkowych testów, a na to byłem zbyt leniwy. Okazało się, że zrobiłem coś w rodzaju literówki - w kliencie użyłem nie tej metody, o której myślałem ;) Ale "literówki" każdemu mogą się zdarzyć (zapraszam na ponowne rzucenie okiem na mail od fejsbuczka).

Dobre testy bronią nawet przed literówkami! (można np. testować zamierzony komunikat błędu z exceptiona  aby uniknąć literówek;) ale wróćmy do rzeczy poważnych) A nawet jeśli nie, to stanowią dokumentację dla kodu, pokazują czy działa i jak działa, dzięki czemu mogą bardzo wydatnie przyczynić się do przyśpieszenia momentu w którym wykryjemy i naprawimy błąd.

Skoro mowa jest o testach, to mogę polecić wpis mojego znajomego, Mariusza Sieraczkiewicza Wielkie kłamstwo o czystym kodzie i testach jednostkowych, a nawet bardziej komentarz, którzy pojawił się pod nim:


Motywacja i chęć doskonalenia swoich umiejętności to jedno, ale same chęci nie wystarczą. Zdecydowana większość osób, które nie uznają testów jednostkowych - tak na prawdę nie wie jak pisać testy i kod, który da się testować. Mnie to nie dziwi, bo wg mnie trudno jest znaleźć dobre materiały na ten temat. Dodatkowo sama teoria nie wystarczy, potrzebna jest praktyka. Tutaj jest problem, bo jeśli zapragniemy zdobytą wiedzę teoretyczną wdrożyć do projektu, nad którym pracujemy w pracy - to tak jakbyśmy uczyli się jeździć na nartach zaczynając od zjazdu ze ścianki. Katastrofa murowana. Trzeba zaczynać od rzeczy małych i prostych. I powolutku poznawać o co w tym wszystkim chodzi.

To wyżej tłumaczy dlaczego tak mało osób używa technik TDD. Jest jednak jeszcze jeden problem: bardzo łatwo jest popełnić błędy podczas poznawania tajników metodyki TDD i zostać jej zagorzałym przeciwnikiem.

Na to wszystko nakłada się jeszcze kolejny aspekt - testy jednostkowe to tylko mały i stosunkowo prosty kawałek układanki. Schody się zaczynają kiedy przychodzi nam ogarnąć testami szerszy zakres: mówię o testach funkcjonalnych i integracyjnych. Tutaj trzeba już czegoś więcej niż poznania kilku prostych zasad, jak ma to miejsce w przypadku testów jednostkowych.

Podsumowując: pisanie o tym, że trzeba pisać testy i że te testy to jest podstawa itp. rzeczy - to nie wystarczy. Tutaj potrzebna jest edukacja "od podstaw", jak czynią to np.:
  • Steve Freman i Nat Pyrce w swojej doskonałej książce (polecam!),
  • Misko Hevery na swoim doskonałym blogu (polecam!),
  • Gregory Moeck w swojej doskonałej prezentacji o tym dlaczego nie pojmujecie mock'ów (polecam!),
  • i inni... (szukajcie, a znajdziecie).

Zadałem sobie nieco trudu i rozszyfrowałem wszystko o czym napisał Witold Szczerba ;)
  1. Misko Hevery i jego blog 
  2. Gregory Moeck i jego rzeczona prezentacja
  3. i inni ;)

powodzenia!

Sunday 26 August 2012

Ksiązki, znowu książki

If you don't know polish - just go directly to Programmers Don't Read Books -- But You Should (written by Atwood, so it's worth reading;)).

After reading that article, I'd like to put my hands on 2 books that were mentioned there (let's say it's my recommendation and essence of whole this entry):








Ok, a teraz po polsku. Można? wszystko można ;)

Książki są zajebiste, w ogólności. Mają ten plus, że raczej NA PEWNO ktoś już je przeczytał i mógł je ocenić. Są gusta i guściki, ale załóżmy, że jak ktoś już bierze do ręki książkę "dla programisty", to ma łeb na karku i bzdur na jej temat chyba nie będzie wypisywał ;) Generalnie - zakładanie, że ludzie mają dobre intencje, ułatwia życie. Nie wiem czy powyższe 2 książki są aż tak genialne, aby warto je było przeczytać - wiem tylko:
  • jaką mają średnią na Amazonie
  • nie dotyczą jednej technologi, czyli się raczej nie przedawnią
  • poleca je gość, który jest dla mnie zawodowym autorytetem (chociażby za stworzenie stacka)
  • piszę o nich posta, aby o nich nie zapomnieć ;) - do "Clean Code" się przekonałem i efekt jest lepszy niż sądziłem. Chociaż czasem polskie tłumaczenie jest nieco zabawne ;)

Ale wiem co ja czytałem i co mogę śmiało polecić. Ba, z paroma kumplami opracowaliśmy "algorytm" książek, które trzeba przeczytać, nim się zechce zmienić pracę. Nie będę zdradzać ich personaliów, bo faktycznie czytają je oni w tym celu. I absolutnie nie narzekają! :)

Kolejność nieprzypadkowa:
  1. Effective Java
  2. Clean Code
  3. Refactoring to patterns
  4. Java Concurrency in Practice
Cytat z Clean Code:

You are reading this book for two reasons. First, you are a programmer. Second, you want to be a better programmer. Good. We need better programmers.

Monday 23 July 2012

JVisualVM

"Premature optimization is root of all evil" - I agree with that as mush as I can. But there are times, that you just need to make you code work faster. Joshua Bloch in his Effective Java is has put some light also to this area, for example in Item 5: Avoid creating unnecessary objects or 51: Beware the performance of string concatenation, etc. You can surely call them good practices that have to be known (and ofc most of things that this book is about).

But sometimes knowing basics is not enought, or project is too big to look deeply to every line of code, and  you just need to spot bottle neck quickly... What you need then? Java profiler! 


Guess what... - it's already with SDK (open consone + type jvisualvm), so no aditional effort is needed! Isn't that awesome? :)

Some performance issues in my current work, and especially reading AMA with high performance java code writer were eye openers for me... I will not pretend to be guru, and give you tips how and when you profiler - I'll just provide you with some link, that look permanent, and were enough to start effectively testing my application today's morning.

http://blog.xebia.com/2008/09/15/loitering-objects-make-web-company-lose-money/ - very pleasant to read blog entry, that forced me to try it all on my own - I couldn't write it better, so I don't event try :)

https://blogs.oracle.com/nbprofiler/entry/profiling_with_visualvm_part_1 - less blog-like, slightly less chilling, but this1 has some info that I found missing in previous link.

Both readings combined seems to be even more then you need to try it yourself, with pretty good knowledge what are you doing.

EDIT:
Feel the power of community! ;) - link provided by my mate (thanks Marcin!), that seems to be perfectly fetting in here - Eclipse Memory Analyzer - fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption. This time he seems to be knowing what he's talking about, so this tool should be worth the effort to know more about its capabilities. ;)

Sunday 22 July 2012

"Effective books"

For some selfish reasons, and encouraged by words that I have read today, something like forget about real programming, if you can't read in English - I have made first entry in English. Not Java, nor C/++/C#, Scala etc., English is the most important language in programming. http://stackoverflow.com is a good playground for practicing it, but let's go straight to main topic.


I needed stimulus to write something here, and today it has come!


That stimulus was reading a great AMA (ask me anything) with some successful Polish Java Developer, who is currently working for some real money in Switzerland http://www.wykop.pl/link/1209873/ama-programista-z-doswiadczeniem/# There are tons of interesting questions and answers (of course that's true only if you know Polish;)), that can be good signboards for low and mid experienced programmers, and even more for still wannabe-programmers. One of them was about books that he is recommending.


So, going to the point:

Effective Java

Java Puzzlers

Java Concurrency in Practice








Doing further research I've found another awesome thing to read - a great presentation on the optimizations used by modern JVMs on the Jikes RVM site:
Dynamic Compilation and Adaptive Optimization in Virtual Machines


And... that's all - I'm pretty excited and in rush to read Java Puzzlers*, which seems to be really enjoyable book and next go back to concurrency (I find it being hard to read, but it surely will be rewarding lecture) or take on reading about JVMs optimizations and of course I'm sure that all mentioned readings are worth to be red by you as well.

*UPDATE:  After some reading of Java Puzzlers, I have to say, that I feel disappointed. This book is too much about some error prone things, that are so error prone, which make them obvious that those kinds of code shouldn't be written without some testing before. And in most cases they are so unreadable, that wouldn't be written by anyone in first place. To sum up - if you don't have anything waiting to be red - go for Java Puzzlers, if you do - don't waste you time ;)


BTW. I'm really surprised every time I hear that someone hasn't read at least Effective Java yet...

Monday 11 June 2012

Rozprawka o new i fabryce... fabryce fabryk faryk :)

To był mój powitalny post post na tym blogu, zawierał on sobie, niestety w formie obrazka, link do mojej odpowiedzi na stacku w temacie "Factory Design pattern and keyword 'new'".


Wracam do tego nie dlatego, że był to taki świetny wpis, który faktycznie nadawałby się na bloga, ale dlatego, że dziś przypomniałem sobie o nim, widząc ten obrazek:



Moim zdaniem świetnie oddaje on to o czym napisał  Joshua Kerievsky, którego cytowałem też tam, na stacku:
I’ve seen numerous systems in which the Factory pattern was overused. For example, if every object in a system is created by using a Factory, instead of direct instantiation (e.g., new StringNode(ノ)),the system probably has an overabundance of Factories.

Moja wypowiedź tyczyła się właśnie tego - chłodnej głowy w tworzeniu fabryk do wszystkiego. Fabryki fabryk fabryk. Bezsens. Z reguły używanie słowa kluczowego new przecież nikogo nie boli, mimo, że powstają całe poematy o tym "why 'new' is evil".

Przykładowy poemat - Java's new Considered Harmful - oczywiście, nie chodzi w nim o to, aby nigdy i nigdzie nie używać new, ale niestety niektórzy mają skłonności do zapędzania się i wtedy właśnie może powstać coś w stylu ProblemFactory.

... Nie chcę przepisywać tego, co już kiedyś napisałem na stacku, a co jest podlinkowane u góry tego posta, jak ktoś nie jest leniwy, to sobie kliknie :)



Po więcej odsyłam do wzorowego opisu wzorca fabryki wraz z opisem refaktoringu z nim związanego: Move Creation Knowledge to Factory. Warto, warto! Kiedyś zawodowo zajmowałem się czytaniem i pisaniem o wzorcach, ale ten artykuł, a w zasadzie fragment książki, to najlepsza rzecz o fabrykach, na jaką trafiłem. Polecam każdemu.


W sumie cała książka Joshuy jest jak najbardziej godna polecenia... i zarazem bardzo trudna do wygooglowania w formie pdfa :)





Na sam koniec jeszcze jedna perełka, luźno związana z tym o czym mowa powyżej - kiedy w zamyśle fajny design nie jest fajny, lecz jest problemem:

zle, i gorsze, pomysły na zamianę ifów na coś innego

jako morał można uznać jeden z komentarzy:


Pozwala to spiąć mój post słowami Atwooda, przytoczonymi wtedy na stacku:
The best way to learn to write simple code is to write simple code! Patterns, like all forms of complexity, should be avoided until they are absolutely necessary. That's the first thing beginners need to learn. Not the last thing.

Sunday 10 June 2012

FizzBuzz a TDD

Nim powrócę do pisania bardziej obszernych wywodów
(w kolejce są:
  1. dokończenie wywodów o skrótach klawiszowych w Eclipsie
  2. logowanie, Log4j, tail'owanie logów
  3. rozmowy kwalifikacyjne i zmiana pracy
)


Pora na coś lekkiego i przyjemnego Fizz buzz code kata:





Jeżeli komuś nic nie mówi ta nazwa, to odsyłam do artykułu Why Can't Programmers.. Program?




Fizz buzz code kata from Johannes Brodwall on Vimeo.

Zgadzam z późniejszymi słowami Atwooda, że każdy programista, który jara się programowaniem na tyle, aby czytać blogi poświęcone tej tematyce, już dawno jest w stanie poradzić sobie z FizzBuzzem... nie potrafię sobie wyobrazić choćby jednego znajomego z pracy, który mógłby mieć z tym problem.

Po co więc piszę o tym filmiku? Bo w namacalny sposób pokazuje on korzyści płynące z TDD. 30 minut pisania kodu i ani jednego system outa. Ani jednej niepewności czy nasz kod nadal działa, czy po refactoringu coś się nie wysypie. Jeżeli masz zamiar oswoić się z TDD, to moim zdaniem FizzBuzz powinien być pierwszą rzeczą jaką w nim wykonasz. Po pierwsze jest na tyle prosty, że wyniki i powód do zadowolenia są niemal od razu. Z drugiej zaś strony zadanie można rozwijać ugeneryczniając je w sposób podobny do zaprezentowanego na filmiku, co stwarza spore pole do popisu dla refaktoringu, ale nawet i bez tego jego złożoność jest wystarczająca, aby zacząć wpajać sobie zasadę (think-) red-green-refactor (polecam kliknięcie w linka, serio, fajny wpis).

Dodatkowo filmik obrazuje to o czym pisałem przy okazji porównania Eclipsa do notatnika - im bardziej potrafimy zmusić kompilator do pisania kodu za nas, tym lepiej!

Friday 11 May 2012

Eclipsowe skróty klawiszowe, których wstyd nie znać

W necie jest sporo artykułów w stylu "top10 Eclipse scrouts", "Eclipse shortcuts that every1 should know" lub po prostu  "najbardziej przydatne skróty w Eclipsie". Przed chwilą skończyłem lekturę jednego z nich, który otworzył mi oczy na to jak wiele jeszcze nie umiem i jak koślawo może wyglądać moje pisanie kodu, dla kogoś kto stoi z boku. Oczywiście, znam sporo skrótów, które ułatwiają mi życie każdego dnia, ale mimo wszystko czułem, że czegoś mi brakuje, że pewnie niektóre rzeczy można wykonać sprawniej...

Najlepszą lampką ostrzegawczą jest to to ile razy musimy chwycić myszkę, aby coś zrobić. Pół biedy jeśli klikamy myszką, aby rozwinąć menu od refaktoringu, albo wstawiania kodu - prawdziwą tragedią jest to, gdy ktoś w ogóle nie wie, że takie wynalazki istnieją i większość rzeczy pisze totalnie z palca (a tak robią też i niektórzy "doświadczeni programiści"). Powtórzę jeszcze raz i mocniej - jeżeli musisz zdjąć dłoń z klawiatury i położyć ją na myszce, to pewnie robisz coś źle, pewnie da się szybciej. Pomyśl o tym, do jakich czynności wcześniej była Ci potrzebna myszka, może któraś z nich da się wykonać skrótami, które zaraz zaprezentuję.

By żyło się lepiej, wszystkim :)

Eclipse zawiera w sobie setki skrótów, ja skupię się na tych, które uważam za ważne, ale i tak będzie ich na tyle dużo, że warto je jakoś uporządkować.

Agenda:
  1. Skróty ułatwiające poruszanie się po edytorze.
  2. Skróty ułatwiające dłubanie w kodzie.

Skróty ułatwiające poruszanie się po edytorze:


Open Type (otworzenie typu - klasy lub interfejsu) - Ctrl + Shift + T. Nie trzeba szukać konkretnej klaski myszką, nie trzeba na chybił trafił zaglądać do kolejnego pakiety z nadzieją "o tu cię znajdę"... Tak jest o wiele szybciej.


Eclipse ma to do siebie, że w tym i w podobnych menu, umożliwiających wyszukanie czegoś, owe szukanie jest naprawdę przyjemne - wpisując wielkie litery występujące w nazwie, nie musimy się bawić w wyrażenia regularne (np. wyszukując NullPointerException nie musimy pisać N*P*E, wystarczy NPE :)) - wystarczy wpisać Wielkie Litery występujące w nazwie typu, dodatkowo wyniki można zawęzić podając kolejne fragmenty nazwy, tak jak na załączonym obrazku. Wyrażenia regularne jednak się przydają, bo aby znaleźć NullPointerException, samo Exception to za mało, ale *Exception już w zupełności wystarcza.





Oper Resource (otworzenie dowolnego pliku) - Ctrl + Shift + R. Znowu - znacznie szybsza metoda, niż szukanie czegoś w Project Excplorerze. Kolejną zaletą, widoczną poniżej, jest to, że domyślnie pokazywana jest lista plików, które wcześniej zostały otworzone tym sposobem. XMLe, pliki konfiguracyjne, JSPy, htmle, pierdy dupy żabki - ten skrót może otworzyć właśnie to, czyli wszystkie pliki znajdujące się w projekcie.
































Type Hierarchy (Klasy pochodne, rozszerzane, implementowane interfejsy, itp - pokazanie danego typu w hierarchii ) - F4



Kiedyś używałem tego skrótu dość intensywnie... ale ostatnio odkryłem coś jeszcze lepszego:

Czemu lepszego?
  • naciśnięcie F4 skutkuje tym, że mój must-have widok, czyli Project Explorer chwilowo jest przesłonięty owym Type Hierarchy (oczywiście można to zmienić i przenieść jedno z nich w inne miejsce, ale to jest akurat mniejszy problem), 
  • większą niedogodnością jest to, że aby przełączać się między sub-typami a super-typami trzeba się naklikać myszką...


Wygodniejszą metodą, na otwarcie analogicznego widoku hierarchii, jest użycie  
Ctrl + T



Ponowne naciśnięcie Ctrl + T powoduje szybkie przełączenie się między sub-typami a super-typami a nawigowanie strzałkami i pacnięcie Entera skutkuje otworzeniem danego typu.







Quick outline (podgląd pól i metod w klasie) - Ctrl + O. To samo co w widoku Outline widocznym po prawej stronie. Ale okienko od razu po otwarciu przejmuje focus i można po nim operować strzałkami, w celu przejścia do konkretnej metody (lub pola), bez dotykania myszki :). Szkoda tylko, że scroll na myszce działa dopiero gdy się klinie weń myszką, lub zacznie chodzić po tym okienku strzałkami.

























Ale najbardziej interesujący "ficzer" ukazuje się, gdy wciśniemy Ctrl + O po raz kolejny - rozwija się pełna lista pól i metod obiektu danej klasy, czyli także wszystkich odziedziczonych. Od razu widać też z której klasy co pochodzi.































Go to Line (przejście do linii nr X) - Ctrl + L. Bardzo przydatne, gdy ktoś obok krzyczy "Masz błąd w 3528 linii, napraw to natychmiast!!".



















Search (szukajka) - Ctrl + H


































inne:

Backward history (poprzednie edytowane miejsce) - Alt + Strzałka w lewo

Forward history (natępne edytowane miejsce) - Alt + Strzałka w prawo

Oba skróty są baaaaardzo przydatne, kiedy nie ma się w zwyczaju zamykać otwartych plików i szybko robi się ich kilkadziesiąt lub ponad setka.




Open Editor (lista plików otwartych do edycji) - Ctrl + E









CDN. / W następnym odcinku: Skróty ułatwiające dłubanie w kodzie.
Czyli pisanie, refactoring i naprawianie kodu.

Monday 7 May 2012

Notepad++ vs Eclipse

Niecały rok temu, podczas jednego z technicznych szkoleń, spotkałem pewnego Niemca, ponoć programistę, obecnie Project Managera. W szkoleniu uczestniczył tak jak wszyscy inni. Charakteryzowało go to, że jako jedyny olał uprzednio przygotowanego na VMie Eclipsa, który miał podlinkowane wszelkie potrzebne jary i skonfigurowane wtyczki (m.in. FileSync), które naprawdę były bardzo pomocne. Gość postanowił używać Vi, a klaski kompilować z konsoli, bawiąc się javac. Brawa dla niego, prawdziwy hardkorowiec, był tylko jeden problem... w tym jego wspaniałym Vi udało mu się zrobić mniej więcej nic. A wszyscy radzili, "użyj Eclipsa, to nie boli".

Faktycznie, nie boli, ale co sprawia, że siadając do Eclipsa (lub Netbeansa, czy innego intelija) jesteśmy bardziej produktywni od Niemca, który go po raz pierwszy widzi na oczy? Czemu nasz IDE to coś więcej niż Notepad++ z wbudowanym kompilatorem, który tu i tam potrafi pokolorować nam kod na żółto bądź na czerwono?

Dziwią mnie osoby, które przesiadają się z Eclipsa na Netbeansa, lub odwrotnie, machając przy tym ręką i mówiąc, że to bez znaczenia w czym będą pisać. To wskazuje na to, że nie korzystają z tego co ich środowisko ma im do zaoferowania, degradują IDE do roli notatnika. Faktem jest, że praca programisty to w 80% czytanie kodu (w tym oczywiście własnego - więc piszmy tak, aby się na jego późniejszy widok nie porzygać...) a tylko 20% to pisanie. W te 20% można pewnie jeszcze wliczyć myślenie, planowanie i inne czynności, które same w sobie nie przekładają się na klepanie w klawiaturę. Ale kiedy już siadamy do pisania, to na Boga, róbmy to możliwie najbardziej ergonomicznie, korzystajmy z tego, co ma nam do zaoferowania środowisko programistyczne!

Często w ogłoszeniach o pracę pojawia się wzmianka "znajomość: (...) Eclipse (/Netbeans)", co wcale nie znaczy, że wiemy, że istnieje. Nie znaczy to też, że umiemy tam stworzyć projekt "Hello World!", lub napisać projekt na uczelnie. Nie, nie, i jeszcze raz nie. To znaczy, że nasza praca pod Eclipsem będzie sprawna i efektywna, czyli w praktyce, że potrafimy zmusić Eclipsa, aby pisał za nas kod (i aby czynił to szybko:)). Dla przykładu prosty JavaBean:
package com.blogspot.pmjavnie;

public class Person {

    private String name;

    private String surname;

    private long personalId;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getSurname() {
        return surname;
    }

    public void setSurname(String surname) {
        this.surname = surname;
    }

    public long getPersonalId() {
        return personalId;
    }

    public void setPersonalId(long personalId) {
        this.personalId = personalId;
    }

}
Licząc tabulacje jako 4 spacje, powyższa klasa ma ~630 znaków. Napisanie jej zajęło mi mniej niż 30 sekund, a moje stukanie w klawiaturę to w większości albo ctrl i/lub spacja i/lub enter. Nie uwierzę, że jest na świecie taki mistrz pisania dziesięcioma palcami, który dokona tego szybciej, bez korzystania z żadnego z uroków IDE, nawet on:



Nie ważne co w życiu robisz i tak znajdzie się jakiś Chińczyk (może to Koreańczyk?), który jest w tym lepszy... daj mu jeszcze Razer BlackWidow Ultimate keyboard i już w ogóle pozamiata... heh, ale nie tym razem :)


Każde IDE ma swój urok i nieważne którego używasz, musisz czuć się w nim jak ryba w wodzie. Ja oczywiście skupię się na tym, którego sam używam, Eclipsie.


Jeżeli w Twoim zespole używa się różnych IDE, a Ty jesteś jego liderem, koniecznie naucz się korzystać z każdego z nich, chociaż w takim stopniu, aby znać podstawę obsługi - niejednoktronie szybciej jest podjeść i napisać komuś kawałek kodu, niż tłumaczyć to mażąc po tablicy, lub dyktując komuś co ma pisać. Jeśli nie jesteś liderem, też spróbuj, wbrew pozorom jest to praktyczna wiedza, która szybko nie uleci.



Do rzeczy... Co odróżnia Eclipsa od notatniczka?
  1. skróty klawiszowe
  2. szablony (Templates) kodu 
  3. odrobina magii, która czyni życie jeszcze (znacznie!) piękniejszym.

 CDN. - warto chociaż parę słów napisać o wyższej wyliczance. Pierwsze dwa punkty mówią same za siebie, ostatni to lombok - genialna rzecz! :)

Monday 16 April 2012

Getters and setters - the good parts


Każdy ich używa... ale czemu?

Co nam dają settery i gettery?

- Ukrywają implemenetację!
- Czyżby?
- No tak...
- Na pewno?
- No chyba...

Czym się różni:
public String name;
od:
private String name;

public String getName() { return name; }
public void setName(String name) { this.name = name; }

bo przecież nie ukrywaniem* czegokolwiek...

Owe ukrywanie, czyli enkapsulacja, to jeden z najważniejszych aspektów OOP i zarazem jeden z częstszych motywów podczas rozmów kwalifikacyjnych, więc warto zgłębić ten temat nieco... głębiej. Tym bardziej, że studiach się o tym chyba (a może nie słuchałem...) nie mówi, natomiast w pracy na takie "pierdoły" nie ma czasu. O samej enkapsulacji będzie innym razem, także w kontekście wzorców.

Wracając do setterów i getterów... istnieją ortodoksyjni wojownicy obiektowości głoszący "why getter and setter methods are evil" - http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html - wygląda na fajny artykuł, jednak nie czytałem go, bo spodziewam się co będzie tam napisane. Tak, podejście rodem z JavaBeans ma swoje wady, wśród których prym wiedzie gigantyczny znak zapytania przy "ukrywaniu".

Co jest więc takiego dobrego w setterach i getterach, że były, są i będą używane?

Po pierwsze, wracając do powyższego porównania publicznego pola name typu String z polem prywatnym i akcesorami... Te 2 kawałki kodu nie różniłby się niczym, gdybyśmy nie mieli opcji zmiany tego, co zaproponował nam kompilator podczas wspaniałomyślnego wygenerowania gettera i settera. Settery dają możliwość walidacji danych! Chcesz zamieniać polskie znaki w Stringu na ich "okrojone" odpowiedniki? Nie ma sprawy - zmieniasz jednego settera - i już, wszystko działa. Tak, jednego. Mając do czynienia z polami publicznymi stykamy się z czymś bardzo hardcorowym - wprowadzając zmiany w logice musimy zrobić to w każdym miejscu, gdzie to pole jest ustawiane, to byłoby nie tylko sprzeczne z podstawowymi zasadami programowania, ale po prostu skrajnie głupie.

Wracając jednak do "walidacji" - w każdym przypadku, gdy w setterze dzieje się coś więcej niż standardowe przypisanie nowej wartości (np. walidacja, jakieś efekty uboczne, rzucanie wyjątkiem) trzeba opisać to w Javadocu - wtedy i tylko wtedy. Dokumentowanie tych o domyślnym działaniu to strata czasu.

Po drugie, o dziwo czasem jednak "ukrywają" ;) czyniąc kod odporniejszym na zmiany.

przed:
private boolean alive = true;

public boolean isAlive() { return alive; }
public void setAlive(boolean alive) { this.alive = alive; }
po:
private int hp; // zmiana implementacji!

public boolean isAlive() { return hp > 0; } // stare sygnatury
public void setAlive(boolean alive) { this.hp = alive ? 100 : 0; }
Jest to skrajny przypadek, ale i takie się zdarzają. Zmieniła się implementacja, interfejs pozostał niezmieniony, klasa nadal spełnia swój kontrakt, brawo dla niej, brawo dla nas ;)

//@TODO: jakiś oczywisty kontr przykład - np. zamiana typu z int na long, aby pokazać, że powyższe to raczej wypadek przy pracy niż reguła :)

Po trzecie - polimorfizm. Warto o tym pamiętać, że używanie getterów, setterów i javadoców czyni możliwym to, co byłoby niemożliwe przy zwyczajnym dziedziczeniu publicznego pola. Pola nie są polimorficzne.

Po czwarte - debugging. W środku metody możemy w razie uzasadnionej potrzeby dorzucić breakpointa albo logowanie. Znowu - robimy to tylko jeden raz a efekt staje się globalny.



Ok, to tyle, następnym razem będzie w drugą stronę (czyli co zamiast getterów i setterów), ale na zakończenie jeszcze mała przypowieść "why getter and setter methods are GOOD":
Because 2 weeks (months, years) from now when you realize that your setter needs to do more than just set the value, you'll also realize that the property has been used directly in 238 other classes :-)

Monday 2 April 2012

Aloha świecie!


Cześć. Jak widać powyżej, kiedyś wartościowe treści zamieszczałem stosując miks stackowo-fejsowy, ale nadeszła pora, aby to zmienić. Jako, że mam parę rzeczy do przekazania, od dziś będzie się to odbywać także w formie bloga.

Pisać będę o rzeczach, o których pisać mi się zachce, ale raczej z myślą o innych, niż o sobie. Jestem programistą Javy i o tym najogólniej mówiąc będzie ten blog. O technologiach, wzorcach, dobrych praktykach, rzeczach ułatwiających życie developerom i tym, którzy potem przeklinają czytając ich (i mój) kod.
Ale nie tylko o tym. Postaram się zamieszczać wszelkiej maści "dobre rady" niezwiązane w bezpośredni sposób z kodem, jeśli tylko nie będą one zbyt banalne i oczywiste, aby je opublikować.

Na zakończenie link do postu Jeffa Atwooda, który przeczytałem parędziesiąt minut temu, tuż przed założeniem mego bloga:
http://www.codinghorror.com/blog/2007/10/how-to-achieve-ultimate-blog-success-in-one-easy-step.html

PS: Altimyt sukcesu się nie spodziewam, ale aby blog nie okazał się martwy, postaram się znaleźć czas na pisanie minimum raz na 3 tygodnie.