Software Craftsmanship Saturday vol. 79 - Limity Deep Learningu, Product Thinking + DevOps, Twitter na TORze

1. Deep Learning osiąga swoje limity – co dalej?

Wieszczenie upadku Deep Learningu jest jednym z ulubionych hobby społeczności IT. Regularnie można trafić na różnego rodzaju opracowania wieszczące nową “zimę AI”, jak określany jest okres, który nastąpił po pierwszym nadmiernym “hype” i późniejszym rozczarowaniu realnymi efektami. Zakończyło ją dopiero powstanie “głębokiego uczenia”, które ponownie rozbudziło zainteresowaniu przemysłu szeroko rozumianą “Sztuczną Inteligencją”. Efekty zastosowania techniki bywają różne – od naprawdę efektownych (w prezentowaniu których bryluje niesamowite Two Minute Papers), po takie, które leżą obecnie na cmentarzysku startupów o pięknych wizjach rozsiewanych przed inwestorami i obietnicach zrewolucjonizowania świata, który znamy.

Nekropolia ta ostatnimi laty wydaje się być deczko przepełniona, stąd też wspomniany już wysyp wszelkich wynurzeń starających zracjonalizować oczekiwania. Takich sugerujących, że powoli zbliżamy się już do granicy jeśli chodzi o to, co będziemy w stanie wycisnąć z Deep Learningu – tam gdzie sprawdza się dobrze, będzie sprawdzał się jeszcze lepiej (ale w sposób inkrementalny “one paper a time”). Jednocześnie, w przypadkach użycia gdzie dotychczasowe wdrożenia nie okazały się zadziałać, nie powinniśmy oczekiwać spektakularnych sukcesów.

W bardzo podobnym tonie wypowiada się publikacja portalu nautil.us. Jest to bardzo długi (mnie lektura zajęła ponad pół godziny), ale przez to niezwykle wyczerpujący przegląd problemów z systemami Deep Learningowymi. Autorzy pochylają się nad trudnościami z tworzeniem modeli, jak i masą nieoptymalnyści związanymi z ich użyciem. Nad całością dodatkowo wisi widmo bardzo ograniczone spektrum przypadków użycia, w których uczenie głębokie rzeczywiście “lśni”.

Głównym poruszanym przykładem jest wszędobylskie GPT-3, ale tak naprawdę cofamy się w tekście nawet do lat 50-tych, dzięki czemu stanowi przekrojowe spojrzenie na rozwój branży – jeśli coś zostało dziwnie pominięte, to DeepFake, ale może to wynikać z faktu że nautil.us poświęcił im cały osoby artykuł. Konkluzją całości jest zaś to, że aby posunąć szeroko pojętą sztuczną inteligencję do przodu, niezbędne będzie poszukiwanie nowych kierunków rozwoju technologii – w tekście znajdziecie zresztą kilku potencjalnych kandydatów.

Wspomniana publikacja nie jest jednak czymś całkowicie unikalnym. Nawet w historii naszych sobót już ten temat kiedyś poruszaliśmy. Dlaczego więc do niego wracam? Jak pewnie wśród stałych czytelników zdążyło wybrzmieć, jestem fanem starych dobrych long-readów i ogólnie magazynowej formuły. Każdorazowo poruszam ten temat przy okazji nowych wydań Incrementa od Stripe, ale to nie jedyna regularny periodyk który czytam. Moim drugim ulubieńcem jest właśnie nautil.us – regularnie wydawany magazyn naukowy, którego forma jest dla mnie idealnym wręcz kompromisem między treściami czysto popularnonaukowymi, a czytaniem nieprzystępnych akademickich paperów (czy też nawet cięższych magazynów naukowych jak Science, od którego niestety się odbiłem). A jako, że tematy poruszane w nautil.us rzadko dotyczą typowego świata oprogramowania, nie mam za wiele okazji żeby przeciekły do naszych sobotnich przeglądów – stąd postanowiłem wykorzystać nadarzającą się okazję, żeby Wam go polecić.

Tematyczne edycje w wersji epub (świetnej na czytniki, niestety porzucili w pewnym momencie wydanie tabletowe) to każdorazowo tylko 2.99$. Sam polecam wybrać temat, który Was interesuje i zaryzykować z pojedynczym egzemplarzem – dowiecie się, czy tego typu formuła Wam odpowiada.

Źródła

2. Jak Slack używa “Myślenia Produktowego” w pracach DevOpsowych.

“Myślenie Produktowe” w ostatniej dekadzie urosło nam do rangi Świętego Graala jeśli chodzi o sposób tworzenia nowych rozwiązań IT. Nie stało się to bez przyczyny – ten zbiór technik polegający na ciągłym iterowaniu, pracy blisko użytkownika i skupieniu się na jego potrzebach, a nie mechanicznym klepaniu kolejnych funkcjonalności sprawdził się w boju i pozwolił urosnąć do niesamowitych rozmiarów masie startupów. Od dłuższego czasu coraz głośniej mówi się również o zaletach, jakie może przynieść zastosowanie “myślenia produktowego” również do pracy nad wewnętrznymi platformami, jak i infrastrukturą techniczną.

Dlatego też z naprawdę sporym zainteresowaniem zapoznałem się z publikacją udostępnioną przez Slacka, w której to znana wszystkim firma opisuje swój proces tworzenia wewnętrznej platformy Bedrock, której rolą jest konteneryzacja aplikacji i umożliwienie ich późniejszego releasu na produkcję. Jeśli myślicie, że paru architektów siadło przy tablicy i wyrysowało architekturę, grubo się mylicie. Całość developmentu poprzedzona była szeregiem obserwacji uczestniczących, wywiadów z użytkownikami czy mierzeniem NPSa. Całość tego odświeżającego procesu została opisana w zwięzłym, ale dość dobrze opisującym cały proces artykule – bardzo zachęcam Was do zapoznania się z nim, choćby po to żeby zrozumieć że “można inaczej”.

I w odróżnieniu od wielu innych innowacji w świecie DevOpsowym, ta naprawdę wydaje się robić różnice, a nie po prostu być inna dla faktu bycia “unikalną”.

A jak już mowa o szybko rosnących firmach (scale-upach) to “w gratisie” podrzucę Wam publikację z bloga Martina Fowlera. Tak naprawdę Fowler sam niewiele już pisze, za to udostępnia u siebie przestrzeń dla innych. I w zeszłym tygodniu Tim Cochran, Carl Nygard i Roni Smith rozpoczęli serię artykułów opisującą na jakie przeszkody (od strony technicznej) mogą natknąć się firmy zaczynające łapać trakcję i skalę. Na razie pojawiły się tam dwa artykuły, ale spodziewam się, że całość rozwinie się w pokaźną kolekcję. Już te obecnie dostępne (o długu technicznym i rekrutacji) mają dość ciekawą strukturę, bo potencjalne problemy od razu uzupełniane są o szereg (tak, szereg, a nie pojedynczy Święty Graal) rozwiązań. Będę z pewnością śledził dalszy rozwój całości i jak całość się zakończy, na pewno do tematu tu wrócimy.

Źródła

3. Twitter otwiera się na TORa

A na koniec będzie o ciekawym ogłoszeniu z zeszłego tygodnia (zwłaszcza w kontekście wydarzeń na świecie). Otóż Twitter ogłosił, że ich platforma stała się “natywnie” dostępna w zasobach sieci Tor. Już wcześniej dało się uzyskać dostęp do witryny Twittera za pośrednictwem Tora, nowo uruchomiona wersja dodaje jednak dodatkowe warstwy ochrony do już anonimowego przeglądania i jest zaprojektowana specjalnie dla sieci – stąd moje określenie jej “natywną. Torowy URL Twittera możecie otworzyć np. przy pomocy przeglądarki Brave.

To będzie dobry moment, żeby zresztą opowiedzieć czym Tor właściwie jest. Tor chroni tożsamość użytkowników oraz ich działalność w sieci przed analizą ruchu przy użyciu sieci cebulowych (stąd nazwa The Onion Routing). W sieci cebulowej wiadomości są wysyłane zaszyfrowanymi warstwami, analogicznie do warstw cebuli. Zaszyfrowane w ten sposób dane są przesyłane przez serię węzłów sieciowych zwanych routerami cebulowymi, z których każdy „odrywa” pojedynczą warstwę, odsłaniając kolejny cel przesyłanych danych – pojedynczy router nie wie jednak o ostatecznym celu, a tylko o kolejnym kierunku w ramach sieci. Operatorzy utrzymują wirtualną sieć złożoną z ruterów cebulowych, zapewniającą anonimowość zarówno w sensie ukrycia lokalizacji użytkownika, jak też możliwości udostępniania anonimowych ukrytych usług. Oczywiście opis ten jest znacznym uproszczeniem – jeśli chcecie dowiedzieć się więcej o niuansach Tora, polecam publikację Niebezpiecznika w tym temacie.

“Cebulka” ma tak wielu fanów, jak i krytyków, a podejście do niej bardzo mocno zależy od kierunku, w którym wychyla się nasze indywidualne wahadełko na wskaźniku wolność/bezpieczeństwo. Sytuacja jest zresztą dość analogiczna, jeśli chodzi o szyfrowanie. Od lat trwa debata, na ile fakt, że służby bezpieczeństwa nie mogę łatwo podsłuchiwać ruchu internetowego jest “featurem” czy “bugiem”.

Pozwolę sobie zagrać moją ulubioną symetrystyczną kartą i skomentować całość stwierdzeniem “to zależy”.

A jak już jesteśmy w temacie, to wykorzystam tą okazję do przytoczenia bardzo ciekawego eseju, który wyszedł spod ręki DHH – twórcy Railsów i CTO Basecampa, znanego ze swoich mocno “opinionated” opinii. Całość została zainspirowana przez protesty w Ottawy i zablokowanie miasta przez kierowców ciężarówek, strajkujących z powodu restrykcji covidowych.

Pamiętacie jeszcze? Przez długi czas wydawał się to pewnik do zapisania w historii jako “najważniejszego wydarzenia na świecie w miesiącu luty roku 2022”

Rząd Kanady zdecydował się wtedy na bardzo kontrowersyjne środki, pokroju blokady prywatnych kont bankowych uczestnikom (bądź co bądź) pokojowych protestów. Decyzja wywołała szereg kontrowersji i była szeroko dyskutowana jako jednak spore nadużycie ze strony rządu premiera Trudeo. I właśnie traktując to wydarzenie jako olbrzymie naruszenie ze strony nawet demokratycznej władzy, DHH postanowił zmienić swoją początkowo krytyczną opinie o Krypto, które są jako waluta znacznie bardziej niezależne i niemożliwe do łatwego blokowania. Jest to o tyle ciekawe, że obecnie właśnie to jest przyczyną ich powszechnej krytyki, jako, że potencjalnie mogą pomóc obchodzić sankcje nałożone na Rosję za inwazję na Ukrainę.