Blog (92)
Komentarze (104)
Recenzje (0)
@marcinw2Raport z postępu prac, czyli Sobieski+ MileStone 3

Raport z postępu prac, czyli Sobieski+ MileStone 3

Na początku kilka zrzutów ekranu:

701869
701870
701871
701872

Projekt na chwilę obecną osiągnął już taką dojrzałość, że na upartego możnaby odtworzyć całą główną funkcjonalność pewnego znanego portalu z fantastyką (jest skrypt do migracji danych i są zaimplementowane wszystkie ważne elementy, a całość ma podstawowe elementy bezpieczeństwa).

Aplikacja jest już aplikacją webową w pełnym tego słowa znaczeniu - część kliencka całkowicie sprawdza połączenie z serwerem, a ten uaktualnia klientów (we wszystkich głównych przypadkach).

W międzyczasie wyczyściłem w dużej mierze kod:

  • jest znacznie lepiej opisany niż w MileStone 2
  • same funkcje są krótsze i czytelniejsze
  • praktycznie wszystko jest zmigrowane na język angielski
  • magic numbers pozostały wyłącznie w kilku miejscach (gdzie mogą zostać)
  • używam let zamiast var
  • nie mam mieszanych znaków końca linii (w końcu wygląda to poprawnie pod Linuxem)

Chciałbym się odnieść do kilku uwag:

  • nodemailer pod Windows 10 pomimo poprawnej instalacji wymaga u mnie importu z użyciem ścieżki (wygląda to na jakąś przypadłość nodeJS) i nie wystarcza użycie "require('nodemailer');"
  • konkatenacja stringów vs templaty - pierwszy sposób wydaje się być znacznie czytelniejszy (i nie jest wolniejszy)
  • brak testów - testy to wspaniała rzecz... o ile mamy w miarę stabilny kod. Na poziomie wczesnych MileStone często i gęsto nie jest dobrą rzecz tracić czas na ich pisanie
  • używanie synchronicznych i asynchronicznych funkcji - stopniowo eliminuję te pierwsze
  • "składnia array['text'] = 'something'" - według różnych mądrych źródeł stosowanie tu obiektów może wpływać na wydajność, do tego skoro działa wyśmienicie... ([] zamiast new Array() oczywiście już są)
  • "plik index.js jest zdecydowanie za duży" - mam oddzielny config.js na razie, do tego nie jestem zwolennikiem podziału, dopóki całość nie jest w miarę stabilna (tu daje chyba znać wygoda w pisaniu i naleciałości z C i C++, gdzie lepiej przy kompilacji mieć wszystko razem)
  • "za dużo switch case" - kwestia gustu
  • "logowanie błędów do konsoli, ogarnąłbym jakąś dobrą biblioteką" - na razie tak naprawdę nie ma tu jeszcze przyzwoitego debug pomocnego przy analizie błędów, będę go rozwijał później (nie chcę jednak używać bibliotek)
  • "ogólnie bym zastosował np utils.promisify, aby zmienić funkcje z first error callbacków na Promise'y" - może kiedyś
  • "zmienne nie powinny mieć krótkich nazw, typu t - zwłaszcza, jeżeli jest używana na przestrzeni kilku stron/scrollowań." - tu się zgadzam, kod w dużej mierze został już przeczyszczony

Na dzień dzisiejszy zauważyłem, że V8 w dalszym ciągu wydaje się mieć problemy z obsługą forEach:

for (let index in cacheTexts) {
   entry = cacheTexts[index];
   ...
}

przy trochę większej ilości danych wykonuje się w około 1 ms, a:

cacheTexts.forEach(function(entry) {
   ...
});

potrzebuje nawet 3500 ms.

Innym ciekawym spostrzeżeniem z ostatnich dni jest to, że JavaScript idzie trochę drogą Basica i innych języków programowania - z prostego tworu używanego do wyświetlania okienek typu alert albo sprawdzania poprawności danych formularza pod wpływem zdarzeń przeszedł w coś, co wymaga pewnych mechanizmów współbieżności.

Z tego powodu musiałem zaimplementować mutex (a właściwie semafor z ilością dozwolonych równoczesnych wejść do sekcji krytycznej równych jeden) - używam go przy uaktualnianiu plików z tekstami (bez niego - gdyby z dwóch przeglądarek robić zmianę w dokładnie tym samym pliku w dokładnie tym samym momencie, to wynik zmian w mojej pamięci podręcznej związanej z tym plikiem byłby losowy).

Podsumowując:

  1. Bardzo dziękuję za poprzednie komentarze, zapraszam do pisania nowych, kontaktu, forkowania, itp. (myślę, że właśnie wymiana doświadczeń najwięcej napędza postęp)
  2. Nic nie reklamuję ani nikomu nie wciskam, co najwyżej przedstawiam postęp w pisaniu pewnego potencjalnie bardzo obiecującego projektu (jest na tyle prosty, że można dosyć szybko wejść w pisanie podobnych wprawek)
  3. Teoretycznie dzisiaj każdy mógłby sobie pobrać ten projekt, zaimportować dane z portalu ("php fantastyka.php" spowoduje wygenerowanie plików w /tmp/biblioteka) i pobawić się całą koncepcją.
  4. Mam różne plany co do rozwoju, zobaczymy co przyniesie przyszłość (Minix 3 też miał być edukacyjny, a skończył na milionach maszyn :)). Przykład: pliki, na których testuję, mają ok. 126 MB - w przyszłości być może zdecyduję na używanie LZ4 i kompresję.

Poprzednie wpisy:

  1. Poprzednik (czyli Sobieski w PHP) - https://www.dobreprogramy.pl/marcinw2/CMS-do-serwowania-WWW-w-kilkunas...
  2. Milestone 1 - https://www.dobreprogramy.pl/marcinw2/Jak-napisac-kompaktowego-CMS-run...
  3. Milestone 2 - https://www.dobreprogramy.pl/marcinw2/Jeden-uparty-kaleczy-JavaScript-...
  4. Co nieco o tworzeniu kodu z radością - https://www.dobreprogramy.pl/marcinw2/Hey-Joe-Potrzymaj-mi-piwo-dlacze...
  5. Info o skrypcie w PHP, którego po zmianach użyłem do migracji danych testowych (oryginalnie był to kod do tworzenia plików EPUB ze stron fantastyka.pl i fantastykapolska.pl) - https://www.dobreprogramy.pl/marcinw2/fantastyczne-teksty-a-nawet-wiec...
  6. https://www.dobreprogramy.pl/marcinw2/Epidemia-i-podejscia-do-tematu-w... - ten wpis nie trafił na główną, ale myślę, że jest warty wskazania (spojrzałem krótko na GitHub i wysnułem kilka wniosków na temat jakości kultury programistycznej w różnych krajach w oparciu o dane/kod związany z zarazą)

C.D.N.

Wybrane dla Ciebie
Komentarze (1)