gefira blog

Jestem jedną z tych osób, które dość często wpisują URL-e w address barze przeglądarki, żeby przejść do określonej strony. Korzystam też z bookmarków do zapamiętywania stron, które mogą być dla mnie ciekawe i warte przeczytania.

Inaczej korzystam z bookmarków, a inaczej z address bara. W bookmarkach są te sprawy, do których zaglądam w miarę często, lub które odkładam do przejrzenia na później (rewelacji tu żadnej nie ma ) .

Z address bara korzystam dlatego, że po otworzeniu nowego okienka lub taba przeglądarki, domyślnie ustawiany jest focus na address barze – wygodnie jest mi więc zacząć pisać “ri” i mieć podpowiedziany adres http://www.risks.org/.

Inną jeszcze sprawą związaną z address barem jest to, że chodząc po sieci nie dodaję oczywiście do bookmarków każdej z potencjalnie interesujących stron. Jest pewien zakres stron, które znajdują się pomiędzy tymi, które odwiedzam często i pamiętam ich adresy (te wpisuję w address barze), tymi, które dodałem do bookmarków, bo wiem, że kiedyś mi się przydadzą, a tymi, które odwiedziłem – powiedzmy – 5 godzin temu, a przez te 5 godzin zdążyłem odwiedzić już 40 innych stron, i teraz chcę do jednej z nich wrócić. Ten “pewien zakres” nie jest znowu taki mały, obejmuje zapewne z 99.9% stron, które przeglądam..

Takie są mniej więcej wzorce użycia, które u mnie występują, a przechodząc do właściwego tematu – warto tworzyć strony, które w URL-ach mają slugi wskazujące na treść strony.

Jeśli ktoś często dyskutuje na forum jakiegoś portalu na temat polityki międynarodowej to ma adres http://forum.example.com/0,0,1,603,katalog.html dodany do bookmarków. Jeśli jednak (załóżmy) przeglądam sobie fora portalu i chcę do któregoś wrócić, więc otwieram nowego taba przeglądarki, wpisuję “fo”, i podpowiadają mi się adresy http://forum.example.com/0,0,1,603,katalog.html, http://forum.example.com/0,0,1,105,katalog.html i inne, to w sumie nie mam wyboru tylko muszę odwiedzić po kolei te adresy. Nie mogę skorzystać z historii odwiedzanych dziś stron, ponieważ portal ten stosuje praktykę taką, że wszystkie fora mają ten sam tytuł strony. Mogę wejść w katalog danego portalu, znaleźć te fora od początku. Mogę też skorzystać z wyszukiwarki internetowej. Ale równie dobrze mógłbym nie tracić czasu i zobaczyć od razu w address barze, że ten URL dotyczy polityki międzynarodowej. Tak, to brzmi banalnie, ale jest to jedna z tych spraw, które są proste do realizacji gdy pomyśli się o nich odpowiednio wcześnie, a które potem ułatwiają życie innym ludziom. Wystarczyłoby, żeby adres wyglądał np. tak:
http://forum.example.com/0,0,1,105,katalog,polityka-miedzynarodowa.html. Współczesne frameworki bez problemu wspierają takie rozwiązania, a mam nadzieję, że już nikt nie pisze w servletach czy CGI i nie może dyskutować, że jest to trudne do implementacji. Jeśli w Twoim frameworku nie można tego zrobić to najprawdopodobniej i tak masz więcej zmartwień niż tylko slugi, więc tak czy inaczej, nadszedł czas na migrację do innych narzędzi.

Tak to wygląda w Internecie, ale ważne jest to też w aplikacjach zamkniętych, intranetowych. Jeśli – powiedzmy – użytkownicy oceniający umowy z klientami będą mieli napisane w URL-u “akceptacja-umowy”, w tytule strony wyświetlanym na pasku przeglądarki też będzie napisane “Akceptacja umowy”, to samo jeszcze raz będzie napisane wyraźnie na stronie, to po prostu zwiększa szanse na to, że wpadnie to w oko i nikt tego nie potraktuje jako “Anulowanie umowy”.

Przeglądarki internetowe i tak składają się z elementów GUI, które są całkowicie niezrozumiałe dla użytkowników – nie chodzi więc o to, żeby używać slugów bo może ktoś będzie chciał wpisać ręcznie adres – raz, że instrukcja nie będzie przewidywała takiego kroku, dwa, że tak w ogóle z moich spostrzeżeń wynika, że mało osób wie do czego służy address bar. Nigdy tego nie mierzyłem, nie wiem, może ktoś to systematycznie badał? W każdym razie, chodzi o to, żeby zwiększyć szanse na to, że ktoś odnajdzie na ekranie znajomy tekst w gąszczu elementów graficznych, które są obce i po których wzrok prześlizguje się.

Pomaga to też w supporcie – jeśli dostajesz zgłoszenie, że “system nie działa”, a w URL-u widzisz, że ktoś chce wejść pod adres “https://system/content/sales/309/1/715/15/wyniki-sprzedazy” to dla Ciebie, jako autora/autorki systemu może być oczywiste, w którym miejscu tkwi przyczyna, ale dla supportu przyjmującego zgłoszenie nie byłoby to już takie oczywiste, gdyby nie “Wyniki sprzedaży” w URL-u. Może to być zawsze jakimś hintem, może zawsze skrócić czas rozwiązania, może support przekaże to od razu do właściwych osób, może support będzie mógł od razu odpowiedzieć “Tak, wiemy, są aktualnie problemy z przeglądaniem wyników sprzedaży”, na pewno support ma i tak sporo pracy, więc warto pomagać także w taki drobny sposób.

Pozostaje jeszcze kwestia wyszukiwania. Tak samo w wyszukiwarkach internetowych jak i w rozwiązaniach wewnętrznych, można brać URL-e pod uwagę. Jeśli wdrażamy indekser maili, portali, zasobów na FTP-ach czy dyskach sieciowych itd. to zapewne będziemy chcieli wziąć pod uwagę URL indeksowanej strony. Jeśli ktoś szuka “delegacje” a mamy w indeksie strony zaweriające “delegacje” w URL-u to możemy o kilka procent podnieść trafność takiego hita.

Używajmy więc slugów i nie piszmy http://example.com/foo/7/9/31/825 tylko http://example.com/7/9/31/825/warto-korzystac-ze-slugow-w-url-ach

Obserwowałem sobie ostatnimi tygodniami na www.planet.debian.org boje Theodere’a Ts’o ze zgłoszeniami na temat utraty danych z filesystemu ext4. Gdy pierwszy raz to przeczytałem, to pomyślałem coś w stylu “OK, nowy filesystem, ma swoje problemy okresu niemowlęcego, dajmy mu z rok-półtorej zanim cokolwiek produkcyjnego na nim postawimy”, i nadal mam taką opinię.

Trochę rozbawiło mnie więc gdy przeczytałem artykuły na heise-online.pl i linuxnews.pl o tej sprawie. Nie bardzo rozumiem na czym całe zamieszanie polega, po prostu oprogramowanie jest nowe, wprowadza nowy czynnik do całej układanki zależności komponentów systemowych i okazało się, że inne klocki – z tych czy innych powodów – nie pasują tu za bardzo. Przecież cała sprawa powinna zamknąć się w issue trackerze i nie wyjść nigdzie dalej. Nie ma w tej sytuacji nic niezwykłego, w każdym razie nic na skalę Debiana i OpenSSL z zeszłego roku.

Zrozumiałem jednak przy okazji, że właśnie w ten sposób rodzi się FUD. Dobry FUD musi mieć jakiekolwiek oparcie w prawdzie, a im bardziej jest konkretne tym lepiej. Już słyszę za jakiś czas teksty pre-sales architectów “Nasze oprogramowanie jest niezawodne, nie to co Linux, przecież na pewno pamięta Pan, że Linux ma problemy z utratą danych?”. Żadna z tych osób nie będzie wiedziała, że mowa tu będzie o zamkniętej już wtedy sprawie z ext4 (ani, że chodzi o filesystem, zresztą część z mówiących nie będzie wiedziała co to jest filesystem), ale ciężko będzie cokolwiek odpowiedzieć. W końcu tłumaczy się winny, a winny jest Linux, skoro coś się w tej sprawie działo.