Na chwilę przed wprowadzeniem zakazów organizowania imprez masowych odbyła się we Wrocławiu konferencja Boiling Frogs. Byłem, widziałem, kawę tam piłem - a com widział: opisuję.
N-warstwowe modele domenowe
Mariusz Gil
Prelegent zwrócił uwagę na możliwość wyróżnienia innej typologii “klocków”, jakich używamy w DDD - w dużych projektach. Używając metafory systemu sygnalizacji świetlnej w mieście, wyróżnił następujące byty (idąc za Erikiem Evansem):
Nazwa | Metaforyczny odpowiednik |
---|---|
capabilities | sygnalizator na skrzyżowaniu |
operations | cykle sygnalizacji na skrzyżowaniu |
policies | “zielona fala” |
decision support | automatyczna regulacja cyklami świateł na podstawie bieżącego ruchu samochodów |
commitments | ? |
To są przecież podstawowe rzeczy
Piotr Stapp
- Warte przemyślenia rozróżnienie pomiędzy rzemieślnikiem a architektem (inżynierem). (Trochę na przekór ruchowi “software craftsmanship”. ;) ) W skrócie: rzemieślnik po prostu umie powtarzać jakieś wzorce, a architekt (inżynier) rozumie te wzorce i potrafi tworzyć nowe. Tak jak w budowlance, zwykły majster ma po prostu wiedzieć, jak dobrze wylać beton na strop, a inżynier - wie, dlaczego ten strop się nie zawala. :) Jeśli chcemy być inżynierami, musimy rozumieć, dlaczego coś działa w dany sposób.
- 12 factor app - https://12factor.net/pl/
- Logi w rozproszonym systemie:
- nie można opierać się na kolejności w czasie, bo serwery mają zawsze rozjazd pomiaru czasu pomiędzy sobą,
- można stosować correlation id, ale warto przy kolejnym wywołaniu kolejnego serwisu w łańcuszku, dodawać numerek z oznaczeniem zagłębienia - tak aby móc zbudować nie tyle łańcuch, ale drzewko “wywołań” pomiędzy serwisami.
Prezentacja była bardzo luźno opowiedziana, ale merytorycznie - zdecydowanie polecam Piotra Stappa na każdą konferencję. :)
Microfrontends - czyli jak wdrożyć idee microservices na frontendzie
Marcin Milewicz
Minusy monolitycznego frontendu:
- duże repozytorium (dużo plików),
- zależności między zespołami,
- długi czas budowania.
Jak zrobić microfrontends na froncie?
- build-time integration - czyli po prostu jedno repozytorium, ale moduły w sub-packages; to ma jednak nadal minusy jednego, dużego repo,
- iframes - minusem trudność w ostylowaniu, i niewygodne dla SEO,
- moduły w odrębnych bundlach w JS, czyli “dociągnij bundla i renderuj”
- WebComponents
O pracy zdalnej dla firmy z zagranicy
Maciej Sławik
Bardzo dobra, krótka (15 min) prezentacja o tym, jak szukać i jak znaleźć pracę zdalną dla firmy z zagranicy.
- Portale strcite z oferatmi pracy zdalnej są słabe - te firmy są zalewane ofertami, mogą nawet nie odpowiedzieć na Twoją ofertę.
- Lepiej znaleźć potencjalnego pracodawcę samemu i do niej zaaplikować (oczywiście trzeba sprawdzić, czy firma jest remote-friednly).
- Warto być specjalistą w czymś konkretnym - pracując zdalnie sam, musisz być ekspertem, żeby być w stanie rozwiązywać problemy samemu.
- Postaraj się o profesjonalny profil na Linkedin - zdjęcie od fotografa, można poprosić o rekomendacje.
- Wysyłając CV do różnych krajów, sprawdź, jakie tam są zwyczaje i dostosuj do nich swoje CV - np. w Wielkiej Brytanii nie daje się zdjęcia do CV.
- Lepsza jest firma mała lub średnia, bo łatwiej się dogadać, że chce się być 100% zdalnie.
Czy wydajność to jakość?
Jarek Pałka
Jarek to standupowiec polskich konferencji IT, więc wiadomo, że jest wesoło (i często nie na temat). Najciekawszy był jednak ten link - do artykułu o tym, że, mówiąc w skrócie, obecny przemysł IT jest do dupy, bo w ogóle nie dbamy podstawowe rzeczy związane z wydajnością. No bo jak to możliwe, że np. aplikacja Messenger na telefon z wersji na wersję zajmuje coraz więcej, a funkcjonalności nie jest więcej.
#ąęszcz Rzecz o języku informatyków
Piotr Przybył
Świetna, lekka prezentacja o tym, jak bardzo nasz język branżowy jest odległy od normalnej polszczyzny. Te wszystkie “merdżuję”, “fokusuję się na taskach”, “mitingi”, “tajmlajny” itp. to jest nowomowa. To jest oczywiście w porządku, gdy tego używamy między sobą (każda branża na swoje terminy zawodowe), ale naprawdę warto używać normalnych, polskich odpowiedników, gdy komunikujemy się na zewnątrz. Dzięki temu będziemy lepiej rozumiani.
Tutaj znajdziesz link do prezentacji.
Na Githubie istnieje repozytorium, gdzie wspólnymi siłami próbuje się znaleźć polskie odpowiedniki.
Czy pracując w software housie zmarnuję sobie życie?
Marcin Zabawa
Ciekawa typologia potencjalnych miejsc pracy dla programisty. W skrócie mamy do wyboru takie opcje:
- startup: będzie przygoda, ale i zapierdziel, no i raczej nie ma szans na “craftsmanship”, bo gonimy deadline’y
- firma produktowe: nadgodzin nie ma, można się z produktem identyfikować i trochę wykazać się w “craftsmanshipie”, ale na pewno nie będzie przygód
- software house: w porównaniu do firmy produktowej na pewno poczucie misji jest słabsze (jednak od projektu do projektu), ale więcej przygód i więcej możliwości na wykazanie się jako inżynier
- korpo (czyli “centra usług wspólnych”) - tego wątku prelegent nie poruszył, bo stwierdził, że nie ma osobistego doświadczenia w tym zakresie.