Pamiętam jak kilka lat temu u początku polskiego Internetu, gdy brzęczenie modemu powodowało u mnie zachwyt, a moich rodzicieli przyprawiało o zawał i obawę o kolejny rachunek z tej złej tepsy. Czasy to były takie, gdy to uważałem microshit za największą plagę dopiero otwierającego się przede mną świata, gdy tepsę jechano z lewa i prawa...
Głupio mi trochę za tamte czasy, za moje podejście, za takie myślenie. Czasy się zmieniły i człowiek dostrzega błędy w swoim toku rozumowania. Tepsa oczywiście swoją neostradą przyczyniła się zarówno do rozpowszechnienia szerokopasmowej sieci wszędzie tam gdzie to było niemożliwe, w na prawdę przystępnej cenie (wiele razy zastanawiałem się nad zmianą mojego ISP na neo). Firmę z Redmont cenię za profesjonalne rozwiązania - wszelkiego typu. .NET nie jest jakąś niestabilną popierdółką, wiadomo, programuję w dot necie już trzecie...i tak dalej. Office, Windows, są pakietami najczęściej używanymi w biurach, Microsoft Labs (photosyncth - polecam) i tak dalej. Odbyłem kilka szkoleń, zabieram się do egzaminów. Rozwijam się dostrzegając ogromny potencjał w tych wszystkich "monopolistycznych" rozwiązaniach.
Jednak do czego zmierzam. Ostatnio, myśli przedstawione w pierwszym akapicie tego posta, dotyczą rozwiązań, które nie powinny nigdy na takie traktowanie zasłużyć! A jednak...
Akcja "ściągnij Firefox'a" wielki "download day", ścigajmy się z innymi państwami, pokażmy że my Polacy wybieramy jedyną "słuszną" przeglądarkę. Ja przepraszam, ale samo określanie Firefoxa mianem jedynej słusznej już zakrawa na lekki, informatyczny komunizm. Nie uważam tej aplikacji za jakąś złą czy coś. Jestem przeciwnikiem wciskania ludziom tego typu bzdur. Kończy się to na przykład komentarzami typu "ff ruleez! ie shit!" "czemu wszyscy nie maja FF? tylko debile go nie uzywaja" itp pod licznymi artykułami dot. internetu, jakie można poczytać na idg.pl lub chociażby tech.wp.pl (jesli ff3 sie wiesza to ciebie jaja swędzą tępy ośle!). Oczywiście że debile te komentarze piszą, ludzie co poddali się tej fali open sourcowizmu w sposób maniakalno-ekstremistyczny.
Zainstalowałem sobie FF 3.0 już w wersji beta i taka irytacja jaka mnie spotyka czasem podczas pracy na "gołym" firefoxie, ostatnio spotkała mnie po zainstalowaniu bety IE8.0. Tego posta też piszę w FF, bo niestety IE8 beta nie dała sobie z tym rady ;)
Zależy mi na komforcie pracy, przeglądarki stały się ostatnio systemami operacyjnymi na której odpalamy swoje aplikacje (jak chociażby moja aplikacja dostarczana klientowi poprzez web). Strony internetowe nie są już dokumentem tekstowym opisanym w XMLu. Internet dostarcza nam aplikacje, i właśnie poprzez przeglądarkę możemy je uruchamiać. Co z tego że wszystkie obecne przeglądarki od IE7, FF, Opera 9.5, Safari 3.0 przechodzą ładnie test ACID2, jeśli każda z tych przeglądarek pewne strony wyświetla inaczej? Of coz, developerzy przeglądarek obwiniają teraz developerów witryn za niestosowanie standardów, ale przecież panowie developerzy przeglądarek, dlaczego sami tworzycie każdy produkt na swój sposób? Dlaczego wszystkie browsery nie wyświetlają stron identycznie?
Kończąc - w tym momencie wybieramy przeglądarkę taką jaka nam pasuje. Chcesz mieć wygodę i porządny pakiet all in? Instalujesz Operę. Jesteś maniakiem (pozytywnym), lubisz się bawić w nieskończone modyfikacje? Instalujesz sobie FF. Pracujesz w biurze i masz to generalnie gdzieś, działasz na IE tudzież Safari (Macowcy). Albo i nie, bo po prostu lubisz ten czy inny produkt. I niech Ci nie będzie wstyd przyznać się z czego korzystasz, wszystkie te produkty zostały stworzone dla Ciebie w celu dostarczenia informacji z Internetu bezpośrednio do Ciebie.
2008-08-03
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");
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.
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.
2008-04-18
Web browsers differences (sic!)
Wszystko działa dopóki nie sprawdzisz tego w IE... no niestety różnice w silnikach wszystkich przeglądarkach są ogromne. Nie zwalam tutaj całej winy na Microsoft, każda przeglądarka ma jakieś odchyły od normy. Tutaj padło akurat na IE.
Postanowiłem dynamicznie potworzyć sobie content strony za pomocą DOM. Wszystko ładnie zadziałało i nawet się przekonałem do takiego sposobu dodawanie lub usuwania elementów. Problem pojawił się przy usuwaniu konkretnych wierszy tabeli. Firefox, Opera kasowały, IE nie...
Problem analizował długo wrzucając alert() gdzie się da ;). Wynik poszukiwań: winną okazała się funkcja getElementsByName(name); . Wartość length wiązki elementów do której wrzuciłem wynik metody w ffoxie pokazywał np. 3 (co odpowiadało prawdzie) a w IE:0.
Po przeszukaniu sieci potwierdziły się moje obawy. Najpierw wyczytałem że getElementsByName w IE nie zwraca poprawnie wiązki w blokach DVI, SPAN i TR, lecz okazało się to nieprawdą. Metoda ta nie działa kiedy dynamicznie utworzymy elementy strony właśnie poprzez DOM.
Szybko jednak można to obejść. Posłuży do tego metoda getElementsByTagName(name). Pobrałem wszystkie TRki do wiązki, przeszukałem je pętlą i pousuwałem te, których nazwy szukałem.
Potem przeszukałem jeszcze raz Internet pod tym kątem i oto co znalazłem (przyda się nieraz!):
http://www.dreamincode.net/code/snippet293.htm
No i jeszcze na dodatek na stronie MSDN czytamy że getElementsByName sczytuje zarówno elementy o podanym name jak i id :/ to już troszkę przykre.
Pomógł Maryn.
Postanowiłem dynamicznie potworzyć sobie content strony za pomocą DOM. Wszystko ładnie zadziałało i nawet się przekonałem do takiego sposobu dodawanie lub usuwania elementów. Problem pojawił się przy usuwaniu konkretnych wierszy tabeli. Firefox, Opera kasowały, IE nie...
Problem analizował długo wrzucając alert() gdzie się da ;). Wynik poszukiwań: winną okazała się funkcja getElementsByName(name); . Wartość length wiązki elementów do której wrzuciłem wynik metody w ffoxie pokazywał np. 3 (co odpowiadało prawdzie) a w IE:0.
Po przeszukaniu sieci potwierdziły się moje obawy. Najpierw wyczytałem że getElementsByName w IE nie zwraca poprawnie wiązki w blokach DVI, SPAN i TR, lecz okazało się to nieprawdą. Metoda ta nie działa kiedy dynamicznie utworzymy elementy strony właśnie poprzez DOM.
Szybko jednak można to obejść. Posłuży do tego metoda getElementsByTagName(name). Pobrałem wszystkie TRki do wiązki, przeszukałem je pętlą i pousuwałem te, których nazwy szukałem.
- wiersze = document.getElementsByTagName("TR");
- var i=0;
- while(i< wiersze.length){
- if(wiersze[i].getAttribute("name")==szukanaFraza){
- objPar = wiersze[i].parentNode;
- objPar.deleteRow(wiersze[i].rowIndex);
- i=0;
- continue;
- }
- i++;
- }
Potem przeszukałem jeszcze raz Internet pod tym kątem i oto co znalazłem (przyda się nieraz!):
http://www.dreamincode.net/code/snippet293.htm
- function getElementsByName_iefix(tag, name) {
- var elem = document.getElementsByTagName(tag);
- var arr = new Array();
- for(i = 0,iarr = 0; i < style="color: rgb(0, 102, 0);">length; i++) {
- att = elem[i].getAttribute("name");
- if(att == name) {
- arr[iarr] = elem[i];
- iarr++;
- }
- }
- return arr;
- }
No i jeszcze na dodatek na stronie MSDN czytamy że getElementsByName sczytuje zarówno elementy o podanym name jak i id :/ to już troszkę przykre.
Pomógł Maryn.
2008-03-25
cookie's razem z header location
oto taki problem się zdarzył:
przychodzimy z formularza do części kodu, mamy wszystkie potrzebne dane z $_POST a, część po obróbce chcemy zapamiętać w cookie i przeładować stronę headerem. nic prostszego:
setcookie("informacja", $_POST["informacja"], time()+3600m, "/");
header("Location: index.php?action=back");
voilla! ... nie do końca
okazuje się że takiego cookie nie mamy, próbując mieszać w kodzie dochodzimy do wniosku że cookie nie chcą się nie tylko tworzyć, ale również kasować lub zmieniać. wszystkiemu winne pewnego rodzaju buforowanie strony metodą ob_start(); którą to dodajemy na początku kodu. nie zapominamy również o metodzie ob_end_flush(); lub ob_flush(); którą wpisujemy pod koniec logiki naszego skryptu (nawet po metodzie header(); która wydawałoby się przekierowuje stronę, jednak dokładniej metoda ta wysyła znacznik meta w części head strony, dzięki czemu przeglądarka automatycznie zmienia adres url). do tego momentu kod strony jest wykonywany i buforowany przed wysłaniem.
po takowym zabiegu osiągamy zamierzony efekt.
ps. serwer IIS5 wywołuje podobne objawy jak opisane powyżej, jednak niestety błędu nie powoduje niewiedza programistów (może nie nas konkretnie, ale może programistów, bo IISa też ktoś napisał). dzieje się tak najczęściej, kiedy w adresie strony (po Location: ...) znajdują się niealfanumeryczne znaki (za wyjątkiem "-" oraz "."). polecają aktualizację IIS lub zmianę header("Location: ..."); na header("Refresh 0; ...");
przychodzimy z formularza do części kodu, mamy wszystkie potrzebne dane z $_POST a, część po obróbce chcemy zapamiętać w cookie i przeładować stronę headerem. nic prostszego:
setcookie("informacja", $_POST["informacja"], time()+3600m, "/");
header("Location: index.php?action=back");
voilla! ... nie do końca
okazuje się że takiego cookie nie mamy, próbując mieszać w kodzie dochodzimy do wniosku że cookie nie chcą się nie tylko tworzyć, ale również kasować lub zmieniać. wszystkiemu winne pewnego rodzaju buforowanie strony metodą ob_start(); którą to dodajemy na początku kodu. nie zapominamy również o metodzie ob_end_flush(); lub ob_flush(); którą wpisujemy pod koniec logiki naszego skryptu (nawet po metodzie header(); która wydawałoby się przekierowuje stronę, jednak dokładniej metoda ta wysyła znacznik meta w części head strony, dzięki czemu przeglądarka automatycznie zmienia adres url). do tego momentu kod strony jest wykonywany i buforowany przed wysłaniem.
po takowym zabiegu osiągamy zamierzony efekt.
ps. serwer IIS5 wywołuje podobne objawy jak opisane powyżej, jednak niestety błędu nie powoduje niewiedza programistów (może nie nas konkretnie, ale może programistów, bo IISa też ktoś napisał). dzieje się tak najczęściej, kiedy w adresie strony (po Location: ...) znajdują się niealfanumeryczne znaki (za wyjątkiem "-" oraz "."). polecają aktualizację IIS lub zmianę header("Location: ..."); na header("Refresh 0; ...");
Subskrybuj:
Posty (Atom)
