
OWASP – The Free And Open Web Application Security Project
Najpierw prezentacja Filipa o wtyczkach do Firefoxa, później prezentacja organizacyjna, o OWASPIE.
Wtyczki o których była mowa:
napisać kilka zdań o OWASPIE i poruszanym tematcie: jak zwrócić uwagę użytkowników na to, że bezpieczeństwo aplikacji jest ważne. A kiedy jest ważne?
- w konkursach, gdzie jest regulamin – i nie powinno się dać oszukiwać
- w miejscach gdzie podajemy swoje adresy e-mail (żeby spamboty ich nie przechwyciły)
- w bankach…
- w miejscach gdzie podajemy dane osobiste – żeby nie zostały wykradzione
Link do listy projektów OWASP
http://www.owasp.org/index.php/Main_Page
Dwa dni temu W3C ogłosiło, że Web Content Accessibility Guidelines 2.0 (WCAG) dotarło do momentu, kiedy stało się oficjalną rekomendacją. Trwało to bardzo długo, prace nad WCAG 2.0 rozpoczęły się bardzo dawno temu.
Dla osób, które pierwszy raz spotykają się ze skrótem – WCAG jest zestawem wytycznych, dzięki którym, po ich spełnieniu nasza strona będzie bardziej dostępna (dla użytkowników niepełnosprawnych), WCAG definiuje 3 poziomy dostępności, najłatwiejszy do osiągnięcia “A”, i dwa kolejne, “AA” i “AAA”. Sama witryna W3C osiąga poziom “AA”.
Na pierwszy rzut oka WCAG 2.0 różni się od poprzedniej wersji ilością przykładów, pozytywnych jak i negatywnych – co jest moim zdaniem bardzo przydatne.
ab (Apache Benchmark), to dołączana do dystrybucji Apache aplikacja testująca wydajność serwera http.
Apache Benchmark na podstawie wprowadzonej liczby zapytań do serwera (z czego część może być realizowana jednoczenie) wyświetla nam raport czasowy realizacji poszczególnych zapytań.
Przykładowe zapytanie: jk$ ab -n1000 -c200 -k http://webascrazy.net/ (Uwaga! Ważne, aby pamiętać o końcowym slashu, w przypadku wpisywania samej domeny!) Spowoduje odpytanie serwera na którym jest http://webascrazy.net 1000 razy, z czego, z czego jednokrotnie będzie wysłanych 200 zapytań. Wynik takiego zapytania będzie wyglądać mniej więcej tak:
| Server Software: |
AOLserver/3.4.2 |
| Server Hostname: |
www.onet.pl |
| Server Port: |
80 |
| Document Path: |
/ |
| Document Length: |
80062 bytes |
| Concurrency Level: |
100 |
| Time taken for tests: |
39.487 seconds |
| Complete requests: |
1000 |
| Failed requests: |
432 |
| (Connect: 0, Length: 432, Exceptions: 0) |
| Keep-Alive requests: |
959 |
| Total transferred: |
79873016 bytes |
| HTML transferred: |
79371411 bytes |
| Requests per second: |
25325.07 |
| Transfer rate: |
2022789.83 kb/s received |
| Connnection Times (ms) |
|
min |
avg |
max |
| Connect: |
0 |
46 |
4562 |
| Processing: |
0 |
3534 |
23659 |
| Total: |
0 |
3580 |
28221 |
http://httpd.apache.org/docs/2.0/programs/ab.html
a x zapytańhttp://www.netcoffee.pl/pogodzinach/2006/02/11/kontrola-wydajnosci-apache-benchmark/
Kilka dni temu W3C udostępniło kolejny walidator stron internetowych. Nowe narzędzie sprawdzi nam, czy nasza strona nadaje się do przeglądania w telefonach komórkowych: http://validator.w3.org/mobile/

Logo W3C mobileOK Checker
Zasada działania jest podobno do pozostałych walidatorów, po wpisaniu strony uzyskujemy czytelny raport. Bardzo przydatne narzędzie – jednak aktualnie są jakieś problemy z wydajnością (duże zainteresowanie?).
W związku z tym, możemy się pewnie wkrótce spodziewać aktualizacji Web Developer Toolbara z dodaną opcją walidacji serwisu za pomocą tego walidatora.
Jednocześnie dopisuję ten walidator, do listy z checkami przed uruchomieniem nowej aplikacji internetowej. Tutaj możesz zobaczyć całą listę.
Z Fiddlera z Firefoxem można korzystać na kilka sposobów. Wszystkie wymagają jednak >10 minut czasu na skonfigurowanie, poustawianie itd.

Mała ikonka dodatku w pasku stanu Firefoxa
Dzisiaj kolega z pracy pokazał mi bardzo fajny dodatek: Fiddler Switch (pobierz Fiddler Switch). Dodatek ten instaluje się jako ikonka w pasku stanu Firefoxa, i za pomocą jednego kliknięcia uruchamia Fiddlera, oraz zmienia odpowiednio ustawienia proxy. Bardzo wygodne, bardzo łatwe, bardzo przyjemne.
Dodatkowo:
Często podczas testowania nowego systemu korzystającego np. z bazy danych natykamy się na problem braku danych testowych. Część z nas ma napisane i opatentowane skrypty, które generują nam najczęściej wykorzystywane dane, jednak wiele testów jest przeprowadzanych nierzetelnie właśnie ze względu na brak realnych danych.

Interface generatora danych testowaych na Testerzy.pl
Z pomocą przychodzi tutaj rewelacyjny skrypt ze strony Testerzy.pl: http://generatordanych.testerzy.pl. Generator daje nam możliwość wygenerowania do 5000 wierszy danych.

Przykładowe testowe dane wygenerowane przez generator
Danym możemy zdefiniować dużo (ponad 100) kolumn, do których wartości będą wygenerowane na podstawie wielu reguł, które możemy dowolnie definiwać: hasła, daty, adresy, nazwiska, losowe treści, numery, adresy e-mail. Bardzo dobre narzędzie – polecam i dodaję do listy niezbędnych narzędzi.
FogBugz (oficjalna strona FogBugz) – system zarządzania projektami ułatwiający komunikację zespołom projektowym. Główne funkcjonalności systemu (których jest sporo na rynku) to:
- wiki
- zarządzanie zadaniami
- system bug-trackingowy
- system komunikacji mailowej, z rozbudowanym systemem filtrów
- grupy dyskusyjne
- system harmonogramowania i estymacji czasu realizacji projektu
Muszę się przyznać, że nie korzystałem jeszcze z tego systemu, ale urzekło mnie video reklamujący FogBugz. Polecam obejrzenie, nawet jeżeli nie jesteście zainteresowani zakupem. Trwa 12 minut i jest prowadzony w bardzo luźnym stylu – sporo śmiechu.
FogBugz nie jest tani, kosztuje 25$ / użytkownik / miesiąc – w przypadku hostowania na serwerach FogBugz, lub 1899$ za licencje na 10 użytkowników, kiedy uruchamiamy aplikację na naszych serwerach.
Można przetestować FogBugz, bez ograniczeń funkcjonalnych, przez 45 dni, i to zamierzam zrobić ze swoim zespołem w ciągu najbliższego miesiąca. Pod koniec stycznia napiszę jak się sprawuje – chyba, że wyniki będą szybciej!
Dodam jeszcze, że narzędzie to jest autorstwa firmy, jednego z moich ulubionych publicystów: Joela Spolskyego (Fog Creek Software).
Programowanie ekstremalne – podstawowe zasady