Interaktywna wizualizacja pakietów języka Go i powiązań między nimi, przypominająca podróż przez galaktykę. Bardzo dobry przykład jak za pomocą WebGL można osiągnąć w przeglądarce przyzwoitą wydajność. Poruszamy się za pomocą klawiatury (klawisze W,Q,E,S,D,A, strzałki, Shift) – miłośnicy gier na pewno szybko się odnajdą. Zdecydowanie polecam pełny ekran. Dostępne są też wizualizacje repozytoriów pakietów innych języków programowania.

Pojawia się coraz więcej bibliotek JavaScriptu do wizualizacji grafów. Moją szczególną uwagę przykuły dwie z nich: 3d-force-graph (patrz interaktywna ilustracja obok, ewentualnie na pełnym ekranie) oraz force-graph renderujące grafy odpowiednio w 3D i 2D. W przypadku 3D wykorzystywane jest wspomaganie sprzętowe (GPU) co wspaniale przekłada się na wydajność i pozytywne wrażenia użytkownika.

Listę innych wartych spojrzenia bibliotek znajdziemy na stronie github.com/anvaka/graph-drawing-libraries. Spodobała mi się też biblioteka viz-js (javascriptowa wersja kultowego GraphViz firmy AT&T Labs), a także WebCola.

Dzisiejszy artykuł będzie narzędziach, jakie przeglądarka Google Chrome udostępnia programistom do debugowania i monitorowania aplikacji webowych, pod przyciskiem F12. Dla tych co mają dużo czasu, pełny opis możliwości jest dostępny na stronach Google’a: https://developers.google.com/web/tools/chrome-devtools/. Tutaj zakładam że Czytelnik ma już jakieś pojęcie o tych narzędziach, zapewne już z nich korzysta w jakimś zakresie i chciałby możliwie szybko poszerzyć swoją wiedzę o różne przydatne i ciekawe triki, które pojawiły się ostatnimi czasy, lub były od dawna ale nie są oczywiste.

Task Manager

Kombinacja klawiszy Shift+ESC otwiera managera zadań, w którym możemy zobaczyć zużycie zasobów komputera z rozbiciem na poszczególne zakładki przeglądarki:

Edycja drzewa DOM

Czytaj więcej »

Archaiczny protokół HTTP stosowany w przeglądarkach WWW ma sporo wad. Jak na przykład powiadomić serwer, że użytkownik przestał korzystać z witryny (zamknął okno lub zakładkę z witryną, kliknął link prowadzący do innej witryny)? Ma to duże znaczenie dla celów analitycznych (informacje zwrotne dla twórców treści i reklamodawców), ale również dla twórców aplikacji webowych – chodzi o wyznaczenie momentu w którym można zamknąć sesję użytkownika, wylogować go i zwolnić zasoby serwera. JavaScript oferuje zdarzenie unload, które można przechwycić, ale jego obsługa niesie ze sobą ograniczenia: nie można w nim wykonać asynchronicznego wywołania AJAX. Deweloperzy radzą sobie z tym wykonując synchroniczne wywołanie AJAX (co niepotrzebnie wydłuża czas zamknięcia strony i/lub przejścia do nowej witryny), albo uciekając się do ryzykownych (niestandardowych) sztuczek takich jak tworzenie obiektu Image i wysyłanie danych do serwera w atrybucie src.
Beacon API (Chrome, Firefox, Opera) proponuje eleganckie rozwiązanie: asynchroniczne wysłanie sygnału w tle:

window.addEventListener('unload', function() { navigator.sendBeacon("/log", analyticsData); }, false);

Jedną z głównych przeszkód w e-handlu jest zmuszanie internautów do wypełniania formularzy z danymi karty kredytowej i adresu wysyłki (a nawet zakładania konta) na każdej witrynie na której chcemy coś kupić. Jest to niewygodne i zabiera czas, zwłaszcza na urządzeniach mobilnych.

Opisywany dziś standard wdrożony m.in. przez przeglądarkę Google Chrome działa następująco:

• Dane użytkownika przechowywane są w przeglądarce (dane karty kredytowej, adresu wysyłki, płeć, imię i nazwisko, awatar itp.),
• Od twórcy każdej witryny chcącej skorzystać z takiego „portfela” przy automatycznym wypełnianiu formularza wymaga się trzymania pewnych standardów przy konstrukcji formularza, a także zabezpieczenia strony z formularzem aktualnym certyfikatem SSL,
• Wystarczy że użytkownik jeden raz wypełni formularz tego typu na dowolnej witrynie zgodnej ze standardem (np. tu), aby później można było na innej witrynie wypełnić formularz „jednym kliknięciem”. W praktyce, aby zapobiec nadużyciom, użytkownik musi jeszcze ręcznie podać 3-cyfrowy kod CVC karty kredytowej (patrz rysunek).

Jaki to zatem standard musi być zachowany przy konstrukcji formularza? W HTMLu formularza kluczowy jest tu atrybut autocomplete, który dla każdego rodzaju danych musi przyjąć określoną w standardzie wartość, np. dla pola z numerem karty kredytowej musi to być "cc-number":

Numer karty: <input type="text" autocomplete="cc-number" name="card-num">

Zauważ, że nazwa pola (pole name) ma znaczenie dla serwera WWW przetwarzającego dane formularza, ale nie ma znaczenia dla automatycznego wypełniania formularza. Lista dostępnych wartości atrybutu autocomplete jest dostępna w Internecie.

W odpowiedzi na zdarzenie naciśnięcia przycisku należy wykonać metodę requestAutocomplete() formularza:

      document.getElementById('fill-button').onclick = function( event ) {
        var form = document.getElementById('myform');
        form.requestAutocomplete();
        event.preventDefault();
      }

Przydatne zasoby

• Opis standardu W3C: 4.10.19.8 Autofill,
• RequestAutocomplete – take my money, not my time (artykuł na html5rocks.com)
• Simplify checkout with requestAutocomplete API
• Przykład formularza zgodnego ze standardem,
• Generator numerów kart kredytowych – przydatne gdy chcemy się pobawić, potrzebujemy poprawnego numeru karty kredytowej i kodu CVC a być może nie chcemy podawać swoich prawdziwych danych.

Przydatna uwaga: jeśli chcesz się pobawić i sprawdzić działanie formularza na swojej stronie internetowej, a nie masz aktualnego certyfikatu SSL, uruchom przeglądarkę Chrome z opcją --reduce-security-for-testing.