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.

Take care

Just one word: care





















Clean Code: A Handbook of Agile Software Craftsmanship
Czysty kod (polish edition)

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. ;)

"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...

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.

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!

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.