2008-07-30

XML a'la NBP

Fajnie że tak potężne instytucje jak NBP udostępniają dane w wersji przyjaznej dla developerów. Mowa tu o kursach walut. Udostępniane w formacie XML dane, łatwe do pobrania i zaimplementowania na własnym serwisie.

Jednak malutki mankament stanowczo utrudnia pobieranie danych. Aby mieć dostęp do archiwalnych kursów (od 2002 roku), pliki XML są bardzo specyficznie i niewygodnie nazywane. Nazwa pliku na dzień wczorajszy to: a147z080729.xml, łatwo się więc domyśleć że 080729 to rok, miesiąc, dzień kursu. Numer 147 to numer tabeli NBP, zawierająca dany kurs. Aby się dostać do danych z 28 lipca nie tyle należy podmienić datę co zmniejszyć numer tabeli o jeden. Dlatego przy pobieraniu danych archiwalnych, nieźle trzeba się nakombinować, pamiętając o pomijaniu sobót, niedziel i świąt, inkrementując numer tabeli.

NBP proponuję zrezygnować z numerowania tabeli w nazwie pliku, wystarczy typ tabeli "a" oraz data, aby unikalnie nazwać wszystkie tabele kursów walut.

Troszkę kodu:
$data = date("Y-m-d");
$data2 = date("ymd", strtotime($data));
.....
$j = sprintf("%03d",$i);
$xml = @simplexml_load_file("http://nbp.pl/Kursy/xml/a".$j."z".$data2.".xml");

2008-07-02

CAPTCHA - czy aby nie jesteś wielbłądem?

Wiele już napisano i wiele razy dyskutowano na temat CAPTCHA... tak i ja postaram się dodać coś od siebie, jak zwykle nie określę się jasno ani za ani przeciw.
Samo rozwinięcie skrótu CAPTCHA jest na tyle skomplikowane że zniechęca lub nawet zraża : Completely Automated Public Turing Test to Tell Computers and Humans Apart - masakra... krótko mówiąc, czy aby nie jestem wielbłądem ? :)
Głównym problemem jest rozpowszechnienie CAPTCHA na wszystkich możliwych witrynach internetowych, które oferują jakikolwiek formularz do wypełnienia. Ja sam podczas ostatnio wykonywanego projektu zostałem poproszony o takowe zabezpieczenie. Mimo wewnętrznej niechęci, zaimplementowałem takowe rozwiązanie. Jest to poważne utrudnienie dla zwykłego użytkownika sieci, nie wspominając już o osobach niepełnosprawnych. I teraz powiedzmy sobie czy nasz blog lub nasze forum będzie natychmiast atakowane milionem spamowych wiadomości? Czy nie umiemy włączyć moderacji komentarzy na blogu przed ich ostatecznym wyświetleniem na stronie? Nawet nie uważam, że to przejaw naszego lenistwa. Więcej czasu by mi zajęła implementacja dobrego rozwiązania, updejtowanie go oraz tłumaczenie użytkownikom "dlaczego...". Dla naszych prostych serwisów - rozwiązanie zbędne, w tym wypadku jestem jego przeciwnikiem.
Inna sprawa z potężnymi serwisami (typu google, yahoo), które muszą się bronić niejako automatycznie przed złośliwościami Internetu. Tutaj jak najbardziej widzę sens tego rozwiązania.
I teraz spójrzcie na różne typy implementacji CAPTCHA. Google - proste i czytelne, serwis o ogromnej odwiedzalności, stosuje najprzyjaźniejsze dla użytkownika rozwiązanie, również skuteczne - około 49%. Inne serwisy, inne rozwiązania - skuteczność rzędu 1%.
Dochodząc do sedna sprawy, wszystko co nie zrobimy aby zabezpieczyć swój serwis przed niepożądanymi treściami, tak do końca wystarczy na jakiś czas, ponieważ wszystkie metody implementacji obrazkowego CAPTCHA nie opierają się atakom z sieci. W wypadku małych serwisów typu blog, lub serwis małej społeczności, polecam ręczne moderowanie wpływającej treści.
Pamiętajmy też o ciekawych alternatywach, postaram się conieco naskrobać niebawem.