Dlaczego Cloud IDE nie chcą się przyjąć? I czy powinno nam na tym zależeć? – Software Craftsmanship Weekly #109

1. Bloomberg Businessweek poświęca cały numer tematowi Crypto

Po trochę ponad dwóch latach regularnego pisania tych przeglądów nie czuje się ani odrobinę bardziej dziennikarzem, ale na pewno zacząłem bardziej szanować takich prawdziwych. Dlatego też dzisiejsze wydanie zaczniemy od publikacji Bloomberga. Gazeta wydała bowiem cały numer swojego tygodnika Bloomberg Businessweek poświęcony tylko jednemu tematowi – kryptowalutom. Jeśli nadal jesteś zdezorientowany w tej tematyce, Levine, znany autor finansowy i twórca poczytnego newslettera Money Stuff, przedstawia całość w koherentny, klarowny sposób. Wychodzi poza standardowe dyskusje o Bitcoinie, zahaczając o NFT, DAO, Smart Contracty i inne aspekty tego świata. Całość jest dostępna również w internecie na stronie Bloomberga. Ciekawostka: jest to drugi raz w 93-letniej historii tygodnika, gdy jeden autor napisał cały numer Bloomberg Businessweek (wcześnie było to „What Is Code?” Paula Forda w 2015 roku).

A jeżeli publikacja Bloomberga to dla Was za bardzo podstawowy poziom, to mam coś bardziej technicznego – The Hitchhiker’s Guide to Ethereum. Tekst jeszcze z maja 2022, a więc sprzed The Merge, ale mnie lektura (a czytałem go wczoraj w pociągu) pomogła wreszcie zrozumieć czym do diabła jest DankSharding i jak wygląda roadmapa techniczna całego projektu. Dzięki temu, że autor wchodzi mocno w detale techniczne (jest nawet trochę matmy 😉), tekst nie wpada w pułapkę „Monad będących jak burrito” i nie pozostawia z uczuciem, że mniej więcej wie się o co chodzi, ale dalej się to nie bardzo klei. Wymaga od czytelnika więcej koncentracji (mimo i tak relatywnie przystępnej formuły), ale chyba już tak jest z trudniejszymi tematami – każde zbytnie uproszczenie potrafi bardziej zaciemnić niż pomóc.

Źródła

• „The Crypto Story”
• „What Is Code?”
• The Hitchhiker’s Guide to Ethereum

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!

2. Wyszedł Technology Radar vol. 27

Jeżeli miałbym wskazać największe problemy, z jakimi boryka się branża IT, to oprócz oczywistych oczywistości takich jak źle zarządzane projekty, czy hype driven development itp., to moim osobistym “bólem” jest fakt, że jak na dziedzinę, która lubi przypisywać sobie inżynierskość, mamy potężny problem z weryfikowalności naszych decyzji. Powiedzmy sobie szczerze, w tworzonych przez nas projektach bardzo często potrzebujemy wybrać jedną z wachlarza dostępnych opcji, mając często dość mgliste pojęcie, która z alternatyw będzie lepsza długoterminowo. Nie bez kozery mówi się, że w IT wszystko jest “tradeoffem“, ale pal licho, jeśli bylibyśmy jeszcze w stanie po czasie cokolwiek ocenić i nauczyć się na błędach. Bardzo często tak niestety nie jest – nawet jeśli będziemy w stanie spojrzeć po czasie na powstałe rozwiązanie i zrozumieć jego dobre i złe strony, to tak naprawdę dalej daje nam tylko to mgliste pojęcie, czy alternatywa byłaby lepsza. „The Road not Taken” i te sprawy.

Nie da się długoterminowo i równolegle rozwijać np. dwóch różnych architektur, żeby po roku zaobserwować, która daje lepsze rezultaty. Dodatkowo, tak naprawdę każdy z nas ma szansę w swojej karierze “zaliczyć” kilka większych projektów, rzadko kiedy mając okazję pracować przy dwóch równocześnie i mieć możliwość porównywania różnych podejść. Bardzo wiele reperkusji przychodzi po czasie, co nieraz przy dużej rotacji, jaka jednak panuje w branży sprawi, że nigdy nie dowiemy się, czy nie popełniliśmy błędu, trudno się nam więc na takowych nauczyć. Dlatego też tak cenny jest fakt, że pojawiają się opracowania pokroju Technology Radaru – publikacje pomagające ocenić przydatność poszczególnych technik i narzędzi.

Dobra, wydaje się jednak że niektórym z Was czytających ten tekst należy się małe wyjaśnienie, czym tak naprawdę Technology Radar jest. Otóż jest to wydawana semi-regularnie (zwykle ok. dwa razy do roku) analiza i ocena trendów wyróżniających się w technologicznym świecie, dokonywana przez firmę ThoughtWorks. W firmie pracują takie uznane osobistości naszej branży jak choćby Martin Fowler czy Rebecca Parson, a sama firma jest agencją konsultingową, pracującą z wieloma dużymi klientami na całym świecie przy często kluczowych dla tych firm projektach. Daje im to dość unikalną perspektywę – są w stanie zarówno przetestować różne rozwiązania konkretnych problemów np. porównując, jak sprawdziły się poszczególne podejścia u poszczególnych klientów, jak i mają widoczność na szerokie spektrum problemów, z jakimi duże firmy muszą się mierzyć.

Są osoby, które mają do Radaru nieco krytyczne podejście, traktując go jako nieco skrzywiony pod kątem wyłącznie większych organizacji – co jest pokłosiem tego, że z takimi podmiotami zwykle pracuje ThoughtWorks – ale z mojej perspektywy każdorazowo jest on zbiorem trafnych obserwacji, pozwalających na mocne poszerzenie horyzontów i “wyłuskanie” dla siebie technik i narzędzi, które może w innym wypadku przeszłyby pod naszym (nomen omen) radarem.

Nowa edycja – Technology Radar vol.27, która wyszła w tym tygodniu – główny nacisk kładzie na cztery tematy. Mamy więc trochę refleksji na temat tego, jak ML wszedł pod strzechy, a także stale przebijający się przez Radar temat używania pryncypiów i technik product managementu również w tworzeniu typowo inżynierskich produktów wewnętrznych. ThoughtWorks pochyla się również nad coraz mocniej rozpychających się łokciami serwerach Edge. Ostatnim zaś motywem przewodnim jest modernizacja sposobów, w jaki tworzymy aplikacje mobilne i modularyzacja takowych.

Ale co ja Wam będę opowiadał (choć akurat kiedyś regularnie to robiłem), po prostu zachęcam do lektury całego raportu, którego znajdziecie pod tym linkiem.

Źródła

• Technology Radar vol.27

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!

3. Dlaczego Cloud IDE nie chcą się przyjąć? I czy powinno nam na tym zależeć?

A na koniec porozmawiamy jeszcze o Cloud IDE. Do tego wątku zainspirował mnie tekst Corey Quinna z newslettera „Last Week in AWS”. W swoim środowym eseju The Real Reason Cloud IDE Adoption Is Lagging wziął on na tapet temat Cloud IDE. Zastanawia się w nim nad powodami, dla których ich adopcja jest taka oporna, i wskazuje tą najbardziej oczywistą – UX. Nawet najlepsze rozwiązania pozostawiają wrażenie półproduktu, który ma w sobie coś takiego… nienatywnego. Niby wszystko jest ok, ale czuć, że to tak naprawdę stary paradygmat, tylko trochę siłą wciśnięty w chmurę.

Corey’emu wtóruje Erik Bernhardsson, który ogólnie przygląda się chmurze obliczeniowej jako takiej i stwierdza, że my, jako programiści, jesteśmy branżą która w małym stopniu przeszła „digital transformation”. Wiem, brzmi to zabawnie, ale w swoim tekście We are still early with the cloud: why software development is overdue for a change pokazuje, jak bardzo ciągle w porównaniu do innych branż jesteśmy uzależnieni od desktopowego oprogramowania i naszych potężnych laptopów. Używając przykładów na które się powołuje, nie ma np. łatwego sposobu aby odpalić 1000 funkcji serwerless i zrównoleglić skompilowanie projektu, same chmury wymagają od nas niskopoziomowego konfigurowania np. Security Group po IP, a do deploymentu ciągle używamy adapterów takich jak Docker. I o ile nie z wszystkimi tezami się w tekście zgadzam (lokalność niektórych rzeczy i niezależność od zewnętrznej platformy ma dla mnie zalety), to trudno nie zgodzić, że nasze narzędzia nie do końca dorosły do świata, który sami stworzyliśmy.

Jest jednak jedna firma, która robi całkiem sprawnie to, o czym piszą Erik Bernhardsson i Corey Quinn (no dobra, według tego ostatniego „najmniej źle) – Microsoft. Ale okazuje się, że to też się społeczności nie podoba, choć Geoffrey Huntley – autor rantu Visual Studio Code is designed to fracture, którym się zaraz z Wami podzielę – ma akurat niezłe argumenty. Wszystko rozbija się tutaj o Visual Studio Code – lekkiego IDE, które prawie całe Microsoft udostępnił na wolnej licencji… i prawie robi tutaj wielką różnice. O ile cały projekt można bowiem swobodnie używać jako open-source, to wszystkie dodatki (jak np. Marketplace rozszerzeń czy usługi do zdalnej pracy) pozostają na zamkniętej licencji Microsoftu. Prowadzi to do sytuacji, w której wszystkie otwarte źródła są „upośledzone”, a wytworzenie alternatyw do własnościowych usług M$ jest bardzo trudne – ciężko przebić się ze swoim rozwiązaniem, gdy większość ludzi wybierze pełniejszy pakiet, którym jest Visual Studio Code, a nie VSCodium – wolne, otwarte, ale pozbawione tych wszystkich chmurowych usprawnień o które prosił Erik. Microsoft ma tutaj po prostu niesamowitą przewagę pod kątem możliwości zapewnienia pełnego, wygodnego doświadczenia, co sprawia że alternatywy nie mają jak powstać. Trochę jak z Apple i iOS, gdzie twórcy zewnętrzni mają utrudniony dostęp np. do NFC, a aplikacje Apple nie muszą się pytać użytkownika o uprawnienia jak cała reszta „plebsu”.

Źródła

• The Real Reason Cloud IDE Adoption Is Lagging
• We are still early with the cloud: why software development is overdue for a change
• Visual Studio Code is designed to fracture

PS1: Ukazały się wyniki kwartalnego FMAANG – a że w zasadzie wszystkie (poza Apple i Netflixem) na jakiejś stopie nie dowiozły to na giełdach rzeź – najbardziej oberwały Meta i Amazon. W ruch za tym poszły Hiring Freezy… ale o tym to Wam już pewnie więcej w poniedziałek opowie Mateusz w jego Career Weekly.

PS2: I tak, wiem że Elon ostatecznie przejął Twittera i odwala tam straszną manianę, kazał drukować kod źródłowy i tak dalej. I choć mam trochę ciągoty, to w wydaniu które rozpocząłem od chwalenia klasycznego dziennikarstwa nie będę się bawił w plotka. Jak Wam mało tego, że przejęcie Twittera to zaraz wyskoczy z lodówki, łapcie rysunkowy komentarz do całej sytuacji: