W dniu dzisiejszym popłaczemy sobie nad Atomem (najlepsi umierają młodo), łykniemy trochę „Computer Science”, a także pochylimy nad HTTP/3, które nareszcie doczekało się oficjalnego Request-for-Comments.
1. Ogłoszono koniec Atoma
Czy ktoś jeszcze pamięta Atoma? Jest to edytor, który w mojej głowie rozpoczął trend na tworzenie wysoce rozszerzalnych narzędzi za pomocą JavaScriptu, którego kontynuatorami są takie projekty jak Visual Studio Code czy terminal Hyper. Wpłynął on mocno na cały rynek oprogramowania, ponieważ właśnie na jego potrzeby stworzony został Electron. Framework ten pozwala na tworzenia natywnych aplikacji z wykorzystaniem technologii internetowych, takich jak JavaScript, HTML i CSS. Electron zupełnie (ale tak zupełnie, zupełnie) zmienił w sposób, na jaki tworzymy aplikacje desktopowe – zamiast pisać je od zera, zaczęto po prostu opakowywać strony internetowe w Electronowy kontener.
Sam sporo bawiłem się tą technologią – kiedyś napisałem wersje Google Keepa ubraną w Electrona i nawet parę osób w mojej ówczesnej firmie zaczęło jej używać. Nie powiem – it was fun.
Teraz GitHub (bo to właśnie oni stworzyli Atoma) poinformował o zakończeniu całego projektu. Przyznam, że dla mnie Atom był już dawno martwy, przynajmniej od kiedy zacząłem używać Visual Studio Code. Spędziłem trochę czasu dzisiejszego poranka na próbie zrozumienia, dlaczego VSCode sprawia wrażenie o tyle szybszego niż mój mózg zapamiętał Atoma, i tak naprawdę nie udało mi się znaleźć dobrego wytłumaczenia. Jeśli macie jakieś dobre materiały na ten temat – dajcie proszę znać.
Co ciekawe, Microsoft posiada własną alternatywę dla Electrona, WebView2, o którym mówi się w sieci coraz więcej. Widać, że zespół Electrona poczuł presję i swego czasu opublikował dość gruntowne porównanie, w którym tłumaczyli, że hypowane WebView2 nie jest w jakimś znaczącym stopniu różne od starego, dobrego Electrona. Nie zmienia to faktu, że Microsoft stopniowo przerzuca swoje kolejne usługi właśnie na swoją technologię opartą o silnik Edge (czyli de facto Chromium – jak Electron). Zarówno już wydane Teams 2.0, jak i niedawno ogłoszony One Outlook zasilane są właśnie autorskim rozwiązaniem Microsoftu. Ciekawe, czy w przyszłości należy spodziewać się podobnej tranzycji dla VSCode.
Interesujące są też podane przez twórców powody ubicia projektu. Otóż chcą oni skupić zasoby na Visual Studio Code for Web i GitHub Codespaces. Widać, że Microsoft mocno inwestuje w przenoszenie środowisk programistycznych do chmury, i tak naprawdę nie tylko on. Akurat będąc wczoraj w biurze, miałem z piszącym nasze “frontendowe czwartki” Tomkiem rozmowę o WebContainers i muszę przyznać, że trochę zostałem przekonany, że tego typu rozwiązania naprawdę mają sporo zastosowań. No cóż, Przyszłość jest teraz.
Atom oficjalnie umrze 15 grudnia. Będziecie tęsknić?
Źródło
- Sunsetting Atom
- WebView2 and Electron
- Introducing WebContainers: Run Node.js natively in your browser
- Microsoft is Finally Ditching Electron | by Faisal Khan | Dev Genius
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. Opublikowano liniowe rozwiązanie Problemu Maksymalnego Przepływu.
Mimo nazwy “Software Craftsmanship” w nazwie, ciężko jest mi przytoczyć jakiś motyw przewodni “sobót”. Każda dotyka technologii, ale poza tym hulaj dusza, piekła nie ma. Czasem zdarzają się case studies, czasem polityka, nieraz przewijają się tematy ogólnobranżowe… dzisiaj jednak będzie nietypowo nawet jak na nas, ponieważ dotkniemy tematu stricte akademickiego. W końcu nie codziennie dochodzi do dużego przełomu w sposobach rozwiązywania problem, nad którym algorytmicy głowili się od lat 50 tych. A to właśnie stało się w przypadku Problem Maksymalnego Przepływu.
Zaczniemy od zdefiniowania Problemu Maksymalnego Przepływu dla tych, którzy nie kończyli informatyki, na zajęciach z algorytmiki spali, albo dla zdrowia psychicznego wyparli je z pamięci. W odróżnieniu od algorytmu komiwojażera, który stał się de facto memem, bohater dzisiejszej edycji jest bowiem nieco mniej znany. Służy on określenia tego, ile materiału może przepłynąć przez sieć od źródła do miejsca przeznaczenia, jeśli łącza w sieci mają ograniczoną przepustowość. Przykładowo – dwa tory kolejowe łączą się na zwrotnicy, przez którą równolegle może przejechać tylko jeden pociąg.
Historia rozwoju algorytmów rozwiązujących powyższy problem jest naprawdę burzliwa i to dobry przykład tego, jak działa w nauce iteracyjny proces. Pierwsze rozwiązanie pojawiło się bowiem już w latach 50-tych, ale było to rozwiązanie zachłanne, wielokrotnie iterującym po drzewie. To właśnie jednak nad optymalizacją jego naukowcy skupili się na następne dekady, pozostając przy algorytmie kombinatorycznym. Przełom dokonał się, gdy rozwiązania doczekał się problem znajdowania przepływu prądu o najniższej energii przez sieć przewodów, z których każdy ma dany opór – co okazło się być ściśle związane z Problemem Maksymalnego Przepływu. Dość szybko udało się “podkraść” pomysł od zespołu zajmującego się elektryką, i to właśnie tą metodę stopniowo rozwijano i komplikowano, redukując ilość niezbędnych kroków. Kulminacje możemy obserwować teraz, gdzie w wyniku prac udało się całość sprowadzić do rozwiązania o liniowej złożoności. Jeśli jesteście ciekawi szczegółów historii i rozwiązania, zapraszam do publikacji Quanta Magazine.
Ciekawostką jest fakt, że jeden z naukowców, którzy pracowali nad tym problem jest Dyrektor Centrum Uczenia Maszynowego MIT (MIT Center for Deployable Machine Learning)… profesor Aleksander Mądry (cudowne nazwisko). Sprawdziłem, i naukowiec ten ma polskie korzenie, kończył bowiem Uniwersytet Wrocławski. Pojawia się w artykule Quanty zarówno przy opisie historii rozwiązań, jak i jeden z cytowanych w artykule specjalistów.
Dobra, to co, do czego nam się to może przydać? Bardzo ciekawy przykład znaleźć można w publikacji na HackerNoon, wizualizującej wykorzystanie Problemu na potrzeby wydawania reszty (czyli przepływie pieniędzy), w wypadku kilky osób zarzucających się na wspólny rachunek. Maksymalny przepływ może służyć do modelowania wielu innych procesów w prawdziwym świecie, jak ruch lotniczy czy przesył internetowy. Jest jedno ale – realny świat ma to do siebie, że zwykle nie operuje na aż tak dużych danych, by istniejące rozwiązania nie były w większości wystarczające (nowe rozwiązanie zyskuje głównie przy naprawdę skomplikowanych grafach).
Dodatkowo, algorytm na ten moment jest szalenie skomplikowany i jego implementacja na potrzeby świata realnego może się czymś “bugogennym”. Kolejnymi krokami będą więc prawdopodobnie starania na rzecz jego uproszczenia. Zobaczymy, może już niedługo dzieło sześcioosobowego zespołu naukowców z czterech różnych języków programowania trafi do bibliotek standardowych języków programowania.
Tak czy siak… Science!
Źródła
- Researchers Achieve 'Absurdly Fast’ Algorithm for Network Flow | Quanta Magazine
- Max Flow Algorithm in real life | HackerNoon
- Quantum Chip Takes Microseconds to Do a Task a Supercomputer Would Spend 9,000 Years On
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!
3. Mamy ostateczny kształt HTTP/3
A na koniec – olbrzymi dokument, ale informacja będzie raczej krótka. Otóż The Internet Engineering Task Force (IETF) opublikowała nareszcie standard HTTP/3. Jeżeli macie ochotę przebijać się przez RFC (a może nawet dać jakiś komentarz), oryginalny dokument znajdziecie tutaj. Opisuje on zarówno, jak zmieni się sposób działania protokołu w jaki sposób rozszerzenia HTTP/2 mogą zostać przeniesione do HTTP/3. Stanowi też symboliczne zakończenie prac po stronie IETF – teraz piłeczka jest po stronie społeczności i to jej feedback jest oczekiwany. Słowem – wygrzane na tyle, że nawet Ci mniej odważni mogą zacząć rozważać wdrożenie.
Raczej nie zachęcam do czytania powyższego RFC. Podejrzewam, że tak naprawdę nawet jeśli zamierzacie wdrażać u siebie obsługę HTTP/3, to nie ma najmniejszego sensu, żebyście przebijali się przez ponad 50 stron specyfikacji (tyle ma plik PDF). Mam dla Was coś znacznie przyjemniejszego – bardzo dobry artykuł, który pozwoli zapoznać się, co tak naprawdę przynosi HTTP/3 w przysłowiowe 5 minut. HTTP/3 to masa zmian pod maską, z czego najbardziej kluczową i najłatwiejszą do zapamiętania jest oparcie całości na protokole UDP zamiast TCP/IP. Jeżeli nie wiecie czym takowe się różnią – ten artykuł z Geeks for Geeks powinien rozwiać Wasze wątpliwości.
Zarówno powyższy artykuł, jak i wideo są stare (jeszcze z 2020), ale to nie oznacza, że wiedza w nim zawarta już się zdążyła przeterminować. Upublicznienie RFC jest w zasadzie kulminacją działań, które przez ostatnią dekadę działy się w branży. Podobnie jak HTTP/2, nowa edycja HTTP również rozpoczęła swój rodowód w Google, gdy firma jeszcze w 2012 roku wdrożyła go pod nazwą QUIC. Już w 2013 IETF zaczął z nim eksperymentować, a od tamtej pory społeczność już zaczęła się nim bawić. W sieci nie brakuje w tej chwili pierwszych historii sukcesu, bardzo ciekawą swego czasu opublikował choćby Facebook. A jeżeli ciekawią Was statystyki użycia HTTP/3, Web Almanach (kobyła analizująca, jak tak naprawdę wygląda internet) poświęciła HTTP cały rozdział.
Źródła
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
