Thursday, October 3, 2013

Code Review is not about...


In SML we do code reviews. We do them on daily basis. Actually the point that we are now is a result of long journey that we made. We try different strategies and tools until we went to the place that we are now (but it doesn't mean that we are going to end up here).
During this journey we found many risks and traps that are waiting for a newcomer. That's what this post is all about, traps & misconceptions on code review.



Code control: many organizations uses CR for controlling codebase. Most of them are using pre-commit strategy. In many cases its because those projects are open-source with hundred of commiters. In real life this is quite rare scenario, so if you hired someone it means that you trust him enough to let him commit code to repository. I know that in some organizations there will be temptation to make procedure that will force developers to "review" and "approve" every commit, but it will not guarantee the quality. Moreover people will soon treat code review as "stupid" corporate procedure and will try to hack-it (such changing password every month e.g. people are using passwords like: mypass1, mypass2 etc.).



Hall of blame: Don't user CR for finding scape goats or guilty ones. Let's assume that there was a failure and you found a person who "reviewed" the "bad code" and blame him for not pointing it out. I will cause that development in your company will drastically slow down. People will be pointing out every semicolon not at the right place, because they will be afraid of being scape goat. Your team members will start feeling unconfident and the lack of trust.


"Code" of duty: Don't push on your developers to much. If you force them to make review every day for an hour, soon they will hate it and treat as unfunny duty. Code review is about learning, praising others and giving feedback so it's very social activity. CR could be fun, don't spoil it.




I'm not my code: If your code was reviewed by someone and he left some comment (sometimes even not too nice), don't get angry. He isn't saying that you are a poor developer. That wasn't his intention nor code review is about that. All he did, was criticizing some piece of code (not the author). Code review is all about code, not about you. Don't treat code review tool as forum with "trolls" and people fighting each other. When you will be writing comments try not to be rude or too strict. Try to imagine that your are on the other side reading it.

To sum it up, there is plenty of ways to make code review wrong. Those 4 are the one that I experienced or anticipated, so beware. I promise to write post about "what code review is about".

If you wan't to try out code review tool (fruit of our experience & practices) visit codebrag.com

Used photos:
1. "The Puppet Master" by Henk
2. "ready for duty" by Leonard John Matthews
3. "Polar wolf's argument" by Tambako the Jaguar

Thursday, July 11, 2013

Gdzie kucharek sześć, tam nie ma co jeść - czyli Confitura 2013

W tym roku zdobyć wejściówkę na Confiturę było trudniej niż na niejeden koncert super-mega gwiazdy. Renoma konferencji rośnie i należy się z tego cieszyć. W tym roku doszły mnie słuchy, że "uwaga, uwaga" nie będzie obiadu. Wielu wieszczyło klęskę, puste sale i pojawienie się band głodnych programistów napadających na przechodniów konsumujących kebaby. Jak się jednak okazało plotki były mocno przesadzone. Obiad był, w formie nieco skromniejszej niż zwykle. Ale po kolei.



Rozpoczęcie konferencji, odbyło się z wielką klasą. Panowie z kapituły powitali nas w fartuchach niczym szefowie kuchni w towarzystwie kociołka w którym robiona była konfitura. Bardzo było to pomysłowe i doprawiło konferencję nutką poczucia humoru. Na otwarciu przekazano także symboliczną nagrodę dla firmy Javart za to, że wspierała ona Confiturę (wcześniej Javarsovie) przez wszystkie edycje. Szkoda tylko, że zabrakło w tej chwili ś.p. Pawła Cybulskiego dzięki któremu to wsparcie miało miejsce. Brawa dla kapituły za nagradzanie firm wytrwale budujących społeczność i inwestujących w nią długoterminowo.

W tym roku do wyboru było 5 równoległych ścieżek. Ja swoją rozpocząłem od Storma. Prezentacja pozwoliła zrozumieć elementarne pojęcia jak "spout" i "bolt" oraz zapoznać nas z przyjemnym API które ma Storm. Prowadzący pokazał jak łatwo można uruchomić sobie prostą topologie oraz jak łatwo można budować te bardziej skomplikowane. Co prawda z prezentacji nie można było wynieść wiele więcej, ale mi to specjalnie nie przeszkadzało ponieważ wcześniej bardzo niewiele o Stormie słyszałem, a prezentacja zainteresowała mnie tą technologią. Po krótkiej przerwie wybrałem MapReduce z Moniką Nawrot. Prezentacja także zaczynała się od podstaw i odpowiedzi na pytanie: "Po co nam to całe przetwarzanie w chmurze". Później mogliśmy poznać więcej szczegółów działania funkcji map, reduce i shuffle. Prowadząca pokazała także parę przykładów implementacji z wykorzystaniem Flume, która usprawnia i ułatwia korzystanie z MapReduce'a.

Następnie zaś byłem na moim zadaniem najlepszej prezentacji na Confiturze 2013 czyli z "Czego być może nikt nie powiedział ci o JS, a co jednak powinnaś/powinieneś wiedzieć". Mój firmowy kolega Michał Ostruszka okazał się świetnym prelegentem. Nie tylko przygotował ciekawą prezentację, ale także zaprezentował ją w sposób sprawny, lekki oraz z poczuciem humoru.

Następnie była przerwa obiadowa, podczas której miał nastąpić armagedon wieszczony przez Inków na grudzień 2012. Na szczęście nic się nie stało. Okazało się, że obiad był! Co prawda w formie trochę skromniejszej niż rok temu (gulasz i kanapki), ale każdy kto studiował musi przyznać, że w porównaniu do studenckich obiadów były to nie lada frykasy. Ja po skonsumowaniu gulaszu poszedłem uzupełnić dietę o warzywa oraz mięso (czyli na kebab). Bardzo fajnie, że ta przerwa była na tyle długa, że można było sobie wyskoczyć na kebab czy piwko i spokojnie wrócić na dalszy ciąg wykładów.

Następną prezentacje niestety przegadałem na konferencyjnych korytarzach. Ale cóż to także ważny aspekt konferencji, spotkać długo niewidzianych znajomych czy poznać nowe osoby dzielące tą samą co my pasję. Następnie posłuchałem Tomasza Borka o jednej z bolączek naszej profecji, a mianowicie o różnicach kulturowych dzielących Europę oraz Indie. Myślę, że ta prezentacja pozwoliła mi lepiej zrozumieć naszych kolegów zamieszkujących subkontynent indyjski. Przy następnej sposobności na pewno przetestuje zdobyte informacje.

Kolejnym moim wyborem była prezentacja Marcina Zajączkowskiego o testach mutacyjnych. Temat o którym parę razy słyszałem, natomiast nigdy zgłębiłem  Prezentacja Marcina odpowiedziała na najważniejsze moje pytania. Dowiedziałem się jakie mamy do dyspozycji narzędzia, jakie są ich ograniczenia oraz czy da się tego użyć w prawdziwym projekcie.

Na koniec posłuchałem prezentacji Michała Bartyzla o architekturze systemów. Była to ciekawa historia kilku prawdziwych projektów z morałem. Morał był dość oczywisty, ale często o nim zapominamy, otóż przy podejmowaniu decyzji co do rozwiązań, należy wziąć pod uwagę wiele czynników także tych "biznesowych" i "organizacyjnych", a nie ulegać wyłącznie technicznym nowościom i zachciankom programistów :-)

Potem było rozdanie nagród. Nie wiem czemu, ale jakimś dziwnym trafem nigdy nic nie wylosowałem (na żadnej z edycji). Może w żelatynie jest jakiś kod typu:
while (!lastname.equals("Żuchowski")) { lastname = losuj(); }
:-)

Kapituła przyznała także nagrodę specjalną Jackowi Laskowskiemu, którego każdy chyba zna i który jest ojcem chrzestnym nie tylko Confitury ale także Javarsovii.




Potem razem z grupą szczęśliwych entuzjastów Javy oraz technologii około JVM-owych udałem się na przystanek gdzie czekał na nas "Confitura Bus" sponsorowany przez mojego pracodawcę czyli SoftwareMill. Po podróży w miłym gronie znaleźliśmy się na Spoinie. Na Spoinie można było się nie tylko spoić (piwem ufundowanym przez Touk) ale także pojeść pizze i pograć jedną z wielu gier barowych (cymbergaj, piłkarzyki, bilard oraz kręgle). Można było porozmawiać z Konradem Malawskim o pracy w Ebayu i Scali, zagrać w kręgle z dumnie reprezentującym barwy CitiBanku Jackiem Laskowskim o honor firmy (sorry Jacek, następnym razem się odegrasz). Impreza była naprawdę przednia i trwała dość, długo. Ja jak rasowy kopciuszek zawinąłem się lekko po północy (gdy zegar wybijał po raz 193).

Podsumowując: konferencja bardzo fajna, impreza po prostu super! Kapituła jak zwykle spisała się na medal. Naprawdę myślę, że uszczuplenie budżetu na obiad to był dobry krok. Także, dzięki temu udało się zorganizować tak fajną Spoinę. Lokalizacja w postaci kampusu UW, rewelacyjna. Największe 2 mankamenty poprzedniej edycji czyli brak klimy oraz zbyt gęste ustawienie stoisk sponsorskich zostały wyeliminowane. Jak się okazało, gdzie kucharzy sześciu tam jest i co zjeść, i czego posłuchać, i czego się napić.

Cichy bohater.



Tomek Dziurko niestety w tym roku nie mógł uczestniczyć w konferencji. Tomek dzielnie pracował całe pół roku przygotowując konferencję ale z powodów rodzinnych musiał zostać w domu. Dlatego dla mnie to on będzie cichym bohaterem tej edycji. Mam nadzieje, ze za rok będzie mógł brać udział w tym święcie społeczności razem ze mną. Zrobiłem dla niego wszystko co mogłem, czyli wypiłem jego zdrowie na Spoinie.

Sunday, September 30, 2012

How to configure Hibernate 4 with JTA transaction for unit tests ?

Some time ago I had to configure Hibernate 4 to work with local unit tests with JTA. At the beginning I was a bit worried that it could be painful. But it appeared to be quite easy when I made it work. The big deal was to find out, how to configure hibernate to use JTA transaction manager (not thread local one), because it was hard to find any information, docs or manuals about this topic. So let's start with persistence.xml: Pay attention at transaction-type="JTA" setting. The other think is configuration when EntityManagerFactory is being build: So, the EntityManagerFactory has been build and configured. Now it's time to use it, in this purpose just call "emf.createEntityManager()" and You have ready to use EntityManager. And on the end crucial thing: How to menage transactions in unit test ? It's simple: So enjoy using JTA-like transactions in Your unit tests. Just remeber that this platform is mock implementation and You are not beyond full JEE server, so e.g. Injecting UserTransaction is not the best idea ;-)