Po proprzedniej specjalnej konferencyjnej edycji znowu mamy dla Was przegląd 3 ciekawych linków oraz mały bonusik (bonusik za to że publikacja zamiast w sobotę ukazuje się w niedziele, życie dogoniło autora 😉).
Zapraszam do lektury!
1. Co zrobić żeby dokumentacja nie “ssała”?
Nikt nie lubi pisać dokumentacji, to w zasadzie truizm. Zawsze przestarzała, zawsze będąca ciałem obcym, której zmiany ciężko jest śledzić wraz z kontekstem ewoluującego kodu (aczkolwiek w jednym z projektów miałem do czynienia z ciekawym eksperymentem – dokumentacji na Github Pages, dodawanej do PR wraz z produkcyjnym kodem). Także jednym z postulatów Agile było posiadanie działającego kodu ponad nawet najlepiej napisaną dokumentacją. Zakładam, była to odpowiedź na problem niemożliwie rozbuchanych planów projektowych z lat 80tych, aczkolwiek znam tu głównie dowody anegdotyczne – chciałbym się kiedyś dokopać do jakiejś realnej analizy pokazującej skalę problemu.
Kolejnym krokiem (choć tak naprawdę dokument fundacyjny tego trendu to już prawdziwa prehistoria, datowana na rok 1992) było stwierdzenie, że najlepszą dokumentacją jest kod, co rodzi pewne problemy (o których już choćby w 2005 roku wspominał Martin Fowler). Aktualnie do łask wraca nieco temat tak zwanego “Technical Writing” – aczkolwiek, o ile w moim pierwszym projekcie była to zupełnie osobna rola…
Faktem pozostaje, że każdy chce mieć dobrą dokumentację, a nikt takowej nie chce pisać. Może problem polega na tym, że to nie ludzie zajmujący się programowaniem są tacy krnąbrni, tylko same dokumentacje po prostu źle robione?
Takie jest też podejście twórcy artykułu o znamiennym tytule “Why Your Company’s Documentation Sucks”, gdzie stara się umotywować, że głównym problemem jest fakt wybierania… złej reprezentacji danych. Otóż wysuwanym argumentem jest, że zwykle błędnie próbujemy przedstawić grafowy problem za pomocą struktury hierarchicznej. Nieco na modłę taktowania Jiry jako “źródła wszelkiego zła w IT”, tutaj obrywa się mocno Confluence, aczkolwiek dość podobne zarzuty można wytoczyć wobec np. Github Pages. Jako przykład bardzo dobrze działającej dokumentacji wskazywana są zaś wszelkiej maści Wiki, przykładowo ta ArchLinuxa.
Jako fan map myśli “propsuje” ogólnie podejście bardzo mocno Teraz czekam na dobrą narzędziówkę – nigdy nie byłem w stanie polubić się z Confluence.
Źródła:
- Why Your Company’s Documentation Sucks
- What Is Software Design?
- CodeAsDocumentation
- How JIRA can kill your software team’s productivity
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Jak radzić sobie z problemami z Cache
“W programowaniu są dwie trudne rzeczy: inwalidacja cache i nazywanie rzeczy”.
Ten mocno już wyświechtany cytat jest nieco niesłusznie przypisywany Martinowi Fowlerowi. Jego autorem jest bowiem Phil Karlton, jeden z twórców Netscape. Na obronę Martina, w swoim tekście (w którym rozpromował powiedzenie) wskazuje oryginalnego autora. Internet po prostu jak zwykle zapomniał
Trudne problemy są więc dwa. Na nazywanie rzeczy chyba nic nie poradzimy (co najwyżej możemy przeprowadzić się z “królestwa rzeczowników” – polecam fantastyczny, klasyczny esej, który nie szczędząc ironii pokazuje sytuację w której żyjemy), może zatem w jakiś sposób zaadresować problemy z cache?
Jeżeli czegoś się nauczyłem przez lata w IT, to tego że w inżynierii oprogramowania bardzo trudno mówić o rozwiązaniach idealny. Analizując problem za problemem, dowiadujemy się o kolejnych ograniczeniach wymuszających na naszych aplikacjach kompromisy. Jednym z popularniejszym jest poświęcenie poprawności na rzecz prędkości odpowiedzi, a najlepszym przedstawicielem tego trendu jest właśnie użycie cache. Bo właśnie rzeczona “inwalidacja”, (czyli wyczyszczenie przestarzałych/niepotrzebnych informacji z cache) jest objawem życia w świecie który nie jest idealny.
Szczęśliwie, na każdy “niemożliwy” problem znajdzie się jakieś “wystarczająco dobre” rozwiązanie. I o właśnie tego typu solucjach dla cache mówi artykuł którym się z Wami dzisiaj dzielimy. Autor prezentuje bowiem przegląd rozwiązań nie bazujących TTL – konkretnym, z góry ustalonym czasie życia danych w cache. Rozwiązaniu o tyle trywialnym, co powodującym czasem nietrywialne bugi.
Tekst stanowi ciekawy przegląd alternatywnych rozwiązań. Przy podejmowaniu decyzji o lekturze warto wziąć pod uwagę profil potencjalnego czytelnika – raczej nie znajdziecie tutaj akademickich rozważań, bardziej sposoby jak poradzić sobie z najczęstszymi potencjalnymi przypadłościami aplikacji webowych.
Źródła:
3. Czy Rust rzeczywiście nie nadaje się do programowania asynchronicznego?
Na zakończenie mam tekst z jednej strony bardzo hermetyczny, z drugiej zaś taki, który powi
nien zainteresować wszystkich chcących poszerzyć horyzonty. Popularność Rusta jako języka jest jakimś fascynującym fenomenem. Z jednej strony wszyscy go kochają, z drugiej strony przeciętny programista ma raczej małą szansę spotkać się z jego użyciem. Jak pisaliśmy w jednej z poprzednich edycji, w dużych firmach jest on używany w coraz większej ilości projektów, ale mam wrażenie że do “mainstreamu” ma szansę przebić się dopiero wraz z WebAssembly – czyli jeszcze trochę wody upłynie bo i ta technologia leży w domenie early-adopterów.
Czemu po raz kolejny wspominam tą popularność? Ponieważ, pomimo wielkiej miłości jaką społeczność programistyczna raczy Rusta, czasem internet podchwyci teksty nieco bardziej krytyczne. Jednym z nich jest prezentowana dziś przez nas publikacja, analizująca sposób działania asynchroniczności w tym języku. Tak naprawdę jest to follow up tekstu z roku 2017, gdzie autor po raz pierwszy sygnalizował problemy. W opublikowanym w zeszłym tygodniu tekście pojawiają się bardzo śmiałe stwierdzenia, że problemy są nie do rozwiązania – wynikają bowiem z decyzji projektowych które przyświecały twórcom języka przy jego tworzeniu.
TLDR: O co chodzi? Otóż autor stara się w swoim tekście udowodnić, że cała magia Rusta opiera się na jego obiektach strukturalnych. Większość składni języka oraz dobrych praktyk z niej wynikających zakłada styl pisania oparty właśnie o nie, wykonując instrukcje jedna po drugiej (dla ludzi którzy lubią teorie – jest to tak zwany “direct style”). W momencie kiedy zaczynamy pisać w sposób asynchroniczny, przestawiamy się na tak zwany continuation passing style (potocznie zwany CSP). Powoduje to, że musimy z Rusta robić język funkcyjny, bowiem operacje teraz są wykonywane przez tak zwane “kontynuacje”. W odróżnieniu od takiego Go, który od początku traktował asynchroniczność jako istotny fragment projektu języka, zarówno programiści Rusta jak i jego twórcy musieli pójść na szereg kompromisów przy tworzeniu async/awaita w tym języku. Przy obecnym trendzie na “asynchronizowanie” wszystkich API, Rust traci swoją prostotę i klarowność.
Tekst przebił się w zasadzie do wszystkich istotnych agregatorów. Zarówno na Hacker News, Redditcie, Lobsterze, jak i zresztą pod samym postem można znaleźć bardzo żarliwe debaty czy autor ma racje, czy może jednak przesadza. Wskazywane jest też to, że asynchroniczność tak naprawdę jest niezbędnym elementem języka w 2021, więc naturalnym jest, że i w Rustcie zaczyna mieć ona coraz większe znaczenie.
Jeśli jesteście zainteresowani budową języków programowania – zarówno artykuł, jak i komentarze którymi obrósł stanowią lekturę obowiązkową.
Źródła:
Odkryj więcej treści IT dopasowanych do Ciebie
W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!
Zainstaluj teraz i czytaj tylko dobre teksty!
Bonus: jako branża nauczyliśmy się po raz kolejny, że trzeba robić backupy… najlepiej u innego providera
Dla porządku nie mógłbym o tym nie wspomnieć, aczkolwiek nie będę się tutaj mocno go rozwijał. O pożarze serwerowni OVH pewnie każdy już słyszał, każdy już też pisał, dlatego zamiast po raz kolejny opisywać tą “piękną tragedię” odeślę do fajnego opracowania z VentureBeat. Od siebie zostawię tylko już nieco oklepanego mema, ale myślę że nasza edycja bez niego byłaby mocno niekompletna.
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
