Hej Mireczki, w tym tygodniu w sumie niewiele się dzieje u #devopsiarz
Kurs #golang wciąż trwa, ostatni film o goroutines: https://www.youtube.com/watch?v=bfoc5PWat5U - zapraszam
Czyli coś, z czego Go jest bardzo znane - kwestie wielowątkowości tym razem, więc nie przelewki.
Myślałem też, że zdążę jeszcze z czymś fajnym dotyczącym #devops i #programowanie w tym #programista15k - m.in szukanie #praca i to, co w tej
Kurs #golang wciąż trwa, ostatni film o goroutines: https://www.youtube.com/watch?v=bfoc5PWat5U - zapraszam
Czyli coś, z czego Go jest bardzo znane - kwestie wielowątkowości tym razem, więc nie przelewki.
Myślałem też, że zdążę jeszcze z czymś fajnym dotyczącym #devops i #programowanie w tym #programista15k - m.in szukanie #praca i to, co w tej












Wydaje mi się, że jest to źle, szczególnie z tymi errorami. Nie wiem jak to ugryźć.
#go #golang
if err == nil { ... if err == nil { ... } }Polecam ten artykul na temat "happy path" w kodzie i dlaczego utrzymywanie logiki biznesowej przy lewej stronie (a bledow w prawo) ulatwia czytanie kodu - https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88
@xa0s: czasem ludzie tworza kanal ktorym przesylaja bledy do glownego procesu, robi sie to wtedy troche podobne do zwracania bledow z goroutines tak jak z funkcji. Ale to troche antywzorzec. Bardziej idiomatycznym sposobem na ogarniecie tego jest pakiet
errgroup.https://godoc.org/golang.org/x/sync/errgroup
Errgroup dziala praktycznie tak samo jak waitgroup, z tym ze pozwala na proste zwracanie i obsluge bledow. Jedyna roznica w uzytkowaniu to ze zamiast