Znowu bierzymy na tapet książkę Software Engineering at Google. Tym razem omawiamy temat zasad i utrzymywania porządku w codebase. Poruszamy następujące kwestie:
Bardzo kontrowersyjny temat. Ale chyba takie są najlepsze. Po 10-15 latach kodowania mamy swoje przemyślenia i chcemy podzielić się naszym punktem widzenia. Mamy nadzieję, że będzie kontrowersyjnie. Czy testowanie na froncie ma sens? Jak definiujemy testy jednostkowe, integracyjne i end-to-end? Czym różni się testowanie backendu i frontu? Kiedy warto testować? Na jakie elementy warto zwracać uwagę? Czym jest ROI? Dlaczego kiedyś programiści nie pisali testów, a software powstawał? Czy odchodzi pewna epoka kodowania? Często powstają dyskusje na temat testów, TDD i podejścia do tworzenia kodu. Mam nadzieję, że dajemy trochę argumentów do ponownego przemyślenia tematu. Zapraszam do wysłuchania rozmowy na Spotify, Apple Podcasts, Google Podcasts i poprostujs.pl
Tym razem Marek prowadzi ( prawie ) monolog na temat ciekawych zastosowań JS. Wybraliśmy 2 skrajne tematy: - hardware -> https://www.kickstarter.com/projects/gfw/banglejs-2-the-open-smart-watch - gamedev -> https://mp2.dk/techblog/chowjs/ Poza tym, że pozwalają wykorzystać JS w zupełnie odmiennych środowiskach, to jeszcze ze swojej natury są zupełnie różne. BangleJS 2 to ekosystem w świece open-source. Praktycznie wszystko jest otwarte i możemy dowolnie modyfikować elementy. Natomiast ChowJS jest closed-source z ( mocno ) płatną licencją. Rozmawiamy o dwóch różnych światach. Marek mocno przygotował się do rozmowy, także zapraszam do wysłuchania (mono / dia ) logu.
Najpopularniejszy ( jedyny ? ) sposób na tworzenie aplikacji desktop'owych w JS to Electron. Niestety, wbrew pozorom wrzucenie stworzonej wersji webowej do Electron to nie jest najlepszy pomysł... Rozmawiamy na temat bezpieczeństwa w Electron. Nasza krótka przygoda z Electron'em zupełnie nas nie zaskoczyła i na szczęście szybko się skończyła. Zapraszam do wysłuchania nowego odcinka.
Natrafiłem na ciekawy blog post napisany przez Jessica Kerr na temat pull request'ów. Znalazłem tam kilka ciekawych tez i postanowiliśmy nagrać odcinek. Rozmawiamy: - dlaczego nikt nie chce robić review do pull request'ów? - jak wygląda dobrze zrobione review? - czy warto inwestować tyle czas na sprawdzenie każdej zmiany? - czy pair programming / mob programming jest alternatywą? - jakie widzimy problemy z mob programming? Zapraszam do wysłuchania podcast. Rozmawiamy mocno subiektywnie na bazie naszych doświadczeń.