Gdzieś pomiędzy liniami kodu

Note:  This blog was originally posted on  Softwaremill’s blog Photo by  Vivek Doshi  on  Pexels “Assumption is the mother of all failures” I’m pretty sure that you have heard this sentence. Today I’m going to show you one of the assumptions, that we have made and still believe in. Being aware of this bias can become handy in your everyday work, especially when you’re dealing with hiring new people to your team. Do you recognize this chart? Yes, it's known as the Dunning-Kruger effect in IT (and not only :) ). It is not precise, it's only an assumption about a complex topic and I will explain to you why. What assumption have we made? From the above chart, we can assume that people who start their careers tend to be cocky and feel Godlike. The sad part is, that many of us think like that. I’ve heard so many times that only juniors can be affected by the Dunning-Kruger effect. You know because seniors always know when they are wrong :). That’s forc

During the last few years, I’ve spent a lot of time on the conferences, meetups and workshops. Note:  This blog was originally posted on  Softwaremill’s blog Many of my friends ask me why I am doing this. Is not that a waste of time and money? Couldn’t you do something more productive in that time? Today I will share my point of view: why I attend the conferences and what can you gain if you will follow my steps. 1. People The audience at Scalar 2019 The community of IT is great. But there is a stereotype, that describes us as nerdy people that can talk only about games and joke about the binary system. You know there are 10 types of people in this world, those who understand binary and those who don’t. You may feel like you don’t belong to this community but I can assure you that like every stereotype that is a lie. People which I met at the conferences and meetups were kind, open and cheerful. I saw many of them help to solve other people’s problems from their projects. N

Post Piotrka Przybyła – swoją drogą świetny prelegent. Jeżeli będziecie mieli okazję, musicie zobaczyć jego prelekcje – sprawił, że zacząłem się zastanawiać nad swoimi reakcjami na biznesowe „nie możemy”. Choć Piotrkowi chodziło o coś zupełnie innego, moje myśli zostały pochłonięte długą wewnętrzną dyskusją na pytanie, które sam sobie zadałem. Aby przybliżyć wam mój tok myślenia, powiem wam, że jestem graczem. Czy dobrym? Nie wiem, ale często mi się zdarzało i wciąż zdarza grać z wieloma losowymi osobami. Bardzo lubię gry zespołowe, tak więc tytuły jak CS, LOL, Fortnite nie są mi obce. No i właśnie, tak popularne tytuły przyciągają całe spectrum graczy. Dobrych, początkujących, złych, agresywnych, zrezygnowanych, a nawet takich, którzy chcą opowiedzieć Ci swoją smutną historię życia. Nie robi to problemu, dopóki wygrywamy jako zespół. Problem pojawia się, gdy gracze nie chcą współpracować lub też specjalnie robią wszystko, abyś ty zginął lub też przegrał grę. No i jak możemy zar

Artykuł ten jest wstępem do większej serii. Wyobraźcie sobie świat, gdzie dokumentacja i kod to jedno. Gdzie wymagania biznesu są kompilowane i jesteś pewny, że są spełnione. Świat, w którym kod piszesz jak tekst i nie musisz go odkodowywać. No właśnie! Piękna idea. Narzędzie, które wam dzisiaj przedstawię, bardzo przybliża nas do niej. Przed wami - Mr. Spock! Od jakiegoś czasu używam do swoich testów Spocka. Postanowiłem się z wami podzielić swoimi przemyśleniami na jego temat. Czym jest Spock? Spock jest to framework testowania oraz specyfikacji dla Javy i Grooviego. Używa on runnera Junit’a, więc jest kompatybilny z wieloma fajnymi narzędziami CI oraz IDE. Po co się go uczyć? Spock jest to świetnie napisane narzędzie, którego celem jest zastosowanie BDD w nieco inny sposób, niż dotychczasowe rozwiązania nam oferowały. Dzięki Spockowi możemy pisać specyfikacje w kodzie i mieć tylko jedno miejsce do utrzymania go. Jakie ma zalety? Spock (dzięki użyciu Grooviego) u

Jakiś czas temu natknąłem się na świetną publikację napisaną po francusku (brak linka z powodu sklerozy i nieznajomość francuskiego, żeby znaleźć w google). Opisywała ona sytuacje, która mi utknęła w pamięci i mam zamiar się nią z wami podzielić. Lecz wszystko po kolei… Czym jest prawo Demeter? Prawo Demeter nieformalnie można określić jako „Nie rozmawiaj z nieznajomymi”. Co idzie za tym stwierdzeniem? Otóż metoda danego obiektu może wywołać tylko metody:    - tego samego obiektu,    - dowolnego obiektu przekazanego jako parametr,    - dowolnego obiektu przez nią stworzonego,    - dowolnego składnika klasy, do której należy dana metoda. Mnie osobiście nie podoba się określenie „Nie rozmawiaj z nieznajomymi”. Wolę o prawie Demeter myśleć w sposób: „niech twój obiekt będzie egoistyczny”. Aby zrozumieć moje podejście, musimy zrozumieć, jaki kod łamie to prawo. Człowiek stefan = new Człowiek(„Stefan”); Parówka parówka = new Parówka(); stefan.getKorpus().getZoladek().getZawa

Przez ostatnie półtorej miesiąca, siedziałem i starałem się zrozumieć rozdział po rozdziale książkę Joshua Bloch’a. Muszę wam przyznać, że wydanie trzecie „Efektywnego programowania”, jest ciekawą pozycją. Niestety nie dałem rady przeczytać drugiej wersji ze względu na słabe tłumaczenie więc nie jestem w stanie porównać wydań między sobą. Pomimo to książkę odebrałem bardzo dobrze, chociaż nie była prosta – może i dlatego, że czytałem ją po angielsku?:) Niektóre rozdziały dotyczyły elementów, z którymi nie pracuje na co dzień (chociażby wielowątkowość w Javie) ale wciąż mogłem wyciągnąć cenne lekcje. Bloch w swojej pozycji nawiązał do Javy 8 oraz 9. Kilka rozdziałów jest poświęconych tylko javie 8 oraz bardzo często, w rozdziałach widzimy kod napisany z użyciem lambd i tym podobnych. Autor często również wspomina w ramach danego rozdziału, że „w Javie 8 można to zrobić lepiej”. Niestety zawiodłem się informacjami o Javie 9. Bloch niewiele wspomina o niej a o samej modułowości n

Dowiedziałem się o tym wydarzeniu na, którymś JUGu wrocławskim  (serdecznie tam zapraszam). Za uczestnictwo w spotkaniu dostaliśmy promocje, aby kupić bilety jako early birds (wczesna faza kupowania biletów). Ostatnia faza kupna doszła do 499 złotych, tak więc kwota duża. Pomyślałem - promocja! Czym prędzej kupiłem bilety jeszcze dnia, kiedy dostałem kod promocyjny i czekałem na konferencję. W dniu 13 grudnia 2017 przybyłem na CodeEurope. Chociaż wielką podróżą bym tego nie nazwał, ponieważ dojechałem tramwajem z mieszkania.  Niestety nie biorąc pod uwagę już tego, że przechodzenie z budynku do budynku bez kurtki było niepraktyczne, to konferencja moim zdaniem miała poważne problemy z tłumem ludzi. Agenda również nie przewidywała zbyt dużych przerw, więc na przejście z sali jednej do drugiej miałem 10 minut, a przebicie się przez tłumy ludzi bywało wyzwaniem. Problemem był również katering - otóż nie było go. Przyzwyczajony z innych konferencji nie biorę własnych kanapek na k