W tej wersji nie ma TDD od samego początku, ale testy wejdą później, kiedy okażą się niezbędne. Kilka razy mówiłem dlaczego porzuciłem tamtą wersję zegara. W skrócie - nie da się pisać projektu raz na 2 tygodnie po dwie godziny. Potem na live było przypominanie sobie co wcześniej było w kodzie. A w trakcie jeszcze większość czasu schodziła na dyskusje o pobocznych tematach i pokazywanie różnych rzeczy w odpowiedzi na pytania z czatu. Ten projekt napisałem w dwa tygodnie codziennie dodając coś do kodu. A dopiero potem nagrałem filmiki opisujące zmiany. Takie podejście gwarantuje ukończenie projektu.
@@bumelant na razie myślałem, żeby robić inne projekty w stylu aktualnej serii o zegarze. Jak bym miał robić kolejny projekt o zegarze to pewnie w innym języku. Ale może kiedyś :)
Cześć, podoba mi się formuła podążania najprostszą ścieżką. Sam ostatnio w projekcie wytworzyłem za dużo abstrakcji, które nie wiem czy do końca są zasadne. Skończyło się na zmianie podejścia i wyznaczeniu drogi którą będziemy iść z kilkoma przystankami (na każdym z nich decydujemy czy chcemy isc dalej) więc bardzo podobnie jak u Ciebie. Jak myślisz, czy rozsądnym byłoby w Twoim projekcie tworzyć ADR'y, które udokumentują decyzje jakie będziesz podejmował? Myślę, że nawet teraz na początku jest to zasadne bo już mamy jakieś decyzje, np moduł hd44780 zależy od modułu display itp.
Akurat w tym projekcie ADRy by były nierealne. To jest stuprocentowy prototyp. Kod pisałem w przerwie bożonarodzeniowej i potem się wkręciłem i dodawałem kolejne rzeczy. Decyzja o nagraniu serii na YT powstała już później. Dlatego w tym projekcie ADRów nie będzie. Co do decyzji o modułach to dla mnie ten kod był właśnie odwlekaniem decyzji na później - z góry zakładam, że będę go jeszcze refactorować. Ale faktycznie później pojawią się też decyzje bardziej wiążące. A czy ADRy w prototypie by się sprawdziły? Dla mnie na samym początku to jest kolejna rzecz, która odciąga nas od najprostszej ścieżki. Jak bym robił taki zegar komercyjnie to pewnie pomyślałbym o ADRach dopiero w miejscu gdzie projekt jest teraz (czyli po odcinku nr 12, który dopiero się ukaże, albo aktualny master na githubie). Czyli pierwszy prototyp wykonany, potwierdziliśmy realizowalność projektu, mamy jakieś rozwiązania sprawdzone w praktyce i teraz będziemy pracować nad wersją komercyjną. Szczerze mówiąc pod koniec myślałem o jakiejś dokumentacji w markdownie i chyba nawet ADRach też. Tak samo w kolejnych krokach bym dodawał analizę statyczną, CI i różne inne dobrodziejstwa większych projektów. A sam temat ADRów od strony praktycznej jest ciekawy i chciałbym go eksplorować. Mam w planach kolejny projekt, bardziej skomplikowany i wtedy bardzo możliwe, że ADRy i inne procesy i narzędzia będą mi potrzebne zanim dojdę do realizacji wszystkich założeń.
Ze względu na ukrywanie prywatnych informacji modułu. Header zawiera publiczne definicje wykorzystywane przez inne moduły. Nie chcemy dawać innym modułom wiedzy o konkretnych pinach naszego wyświetlacza, nie chcemy żeby używały je w swoim kodzie i przy ewentualnych zmianach nie chcemy modyfikować zbyt dużo plików. Dlatego w publicznych headerach lepiej dawać tylko to co faktycznie jest niezbędne zewnętrznym modułom.
![[Zegar szachowy #3]: Wybór trybu gry (interfejsy)](http://i.ytimg.com/vi/X2n3Q60DVtY/mqdefault.jpg)
![[Zegar szachowy #3]: Wybór trybu gry (interfejsy)](/img/tr.png)
![YoungBoy Never Broke Again - Missing Everything [Official Video]](http://i.ytimg.com/vi/dTYeMZGzOzw/mqdefault.jpg)
Ale metamorfoza. Poznałem dopiero po głosie ;)
Dawno nie grałem w szachy... 😉
Szkoda, ze nie ukończyłeś pisania zegara szachowego z użyciem TDD. Zapowiadało się ciekawie.
W tej wersji nie ma TDD od samego początku, ale testy wejdą później, kiedy okażą się niezbędne.
Kilka razy mówiłem dlaczego porzuciłem tamtą wersję zegara. W skrócie - nie da się pisać projektu raz na 2 tygodnie po dwie godziny. Potem na live było przypominanie sobie co wcześniej było w kodzie. A w trakcie jeszcze większość czasu schodziła na dyskusje o pobocznych tematach i pokazywanie różnych rzeczy w odpowiedzi na pytania z czatu. Ten projekt napisałem w dwa tygodnie codziennie dodając coś do kodu. A dopiero potem nagrałem filmiki opisujące zmiany. Takie podejście gwarantuje ukończenie projektu.
@@ucgosupl niekoniecznie musiałeś kontynuować ten projekt na żywo. Myślę, że warto by było go ukończyć, bo zostało już dużo zrobione.
@@bumelant na razie myślałem, żeby robić inne projekty w stylu aktualnej serii o zegarze. Jak bym miał robić kolejny projekt o zegarze to pewnie w innym języku. Ale może kiedyś :)
Cześć, podoba mi się formuła podążania najprostszą ścieżką. Sam ostatnio w projekcie wytworzyłem za dużo abstrakcji, które nie wiem czy do końca są zasadne. Skończyło się na zmianie podejścia i wyznaczeniu drogi którą będziemy iść z kilkoma przystankami (na każdym z nich decydujemy czy chcemy isc dalej) więc bardzo podobnie jak u Ciebie.
Jak myślisz, czy rozsądnym byłoby w Twoim projekcie tworzyć ADR'y, które udokumentują decyzje jakie będziesz podejmował?
Myślę, że nawet teraz na początku jest to zasadne bo już mamy jakieś decyzje, np moduł hd44780 zależy od modułu display itp.
Akurat w tym projekcie ADRy by były nierealne. To jest stuprocentowy prototyp. Kod pisałem w przerwie bożonarodzeniowej i potem się wkręciłem i dodawałem kolejne rzeczy. Decyzja o nagraniu serii na YT powstała już później. Dlatego w tym projekcie ADRów nie będzie. Co do decyzji o modułach to dla mnie ten kod był właśnie odwlekaniem decyzji na później - z góry zakładam, że będę go jeszcze refactorować. Ale faktycznie później pojawią się też decyzje bardziej wiążące.
A czy ADRy w prototypie by się sprawdziły? Dla mnie na samym początku to jest kolejna rzecz, która odciąga nas od najprostszej ścieżki. Jak bym robił taki zegar komercyjnie to pewnie pomyślałbym o ADRach dopiero w miejscu gdzie projekt jest teraz (czyli po odcinku nr 12, który dopiero się ukaże, albo aktualny master na githubie). Czyli pierwszy prototyp wykonany, potwierdziliśmy realizowalność projektu, mamy jakieś rozwiązania sprawdzone w praktyce i teraz będziemy pracować nad wersją komercyjną. Szczerze mówiąc pod koniec myślałem o jakiejś dokumentacji w markdownie i chyba nawet ADRach też. Tak samo w kolejnych krokach bym dodawał analizę statyczną, CI i różne inne dobrodziejstwa większych projektów.
A sam temat ADRów od strony praktycznej jest ciekawy i chciałbym go eksplorować. Mam w planach kolejny projekt, bardziej skomplikowany i wtedy bardzo możliwe, że ADRy i inne procesy i narzędzia będą mi potrzebne zanim dojdę do realizacji wszystkich założeń.
Dlaczego definicje pinów zostały umieszczone w pliku hd44780.c, a nie hd44780.h?
Ze względu na ukrywanie prywatnych informacji modułu. Header zawiera publiczne definicje wykorzystywane przez inne moduły. Nie chcemy dawać innym modułom wiedzy o konkretnych pinach naszego wyświetlacza, nie chcemy żeby używały je w swoim kodzie i przy ewentualnych zmianach nie chcemy modyfikować zbyt dużo plików. Dlatego w publicznych headerach lepiej dawać tylko to co faktycznie jest niezbędne zewnętrznym modułom.
@@ucgosupl wszystko jasne. Dziękuję za wyjaśnienie.