Archiwum
Pisanie testów w JavaScript
JavaScript potrafi być upierdliwe ;).
Pomijając problem z manipulacja DOM, ciężko się tworzy w tym kod, który możesz od razu sprawdzić czy debgować. Teraz trochę się to zmieniło, porównując to do czasów kiedy zaczynałem się poważniej zajmować JavaScriptem: przykładowo mamy FireBug_a i inne dodatki do przeglądarek, które ułatwiają nam zrozumienie co się dzieje w kodzie.
Jednak problemy typu: brak średnika lub sama literówka w nazwie zmiennej są najczęściej odkrywane w przeglądarce kiedy uruchamiamy daną stronę i widzimy że wyrzucane są wyjątki. Taki błędy odkrywane są powoli.
Rozwiązanie tych problemów może być pisanie testów. Wymaga to jednak pewnego zachodu np. porządku w plikach js, tak aby nie ciągnąć za sobą zbyt dużo zależności. Do końca sam nie wiem jak się do tego dobrze zabrać.
Sposób jaki postaram się tu przedstawić jest dobry do testowania prostych koncepcji lub nauki JavaScriptu.
Wszystko zaczyna się od narzędzia jakim jest js-test-driver. Pod podanym linkiem jest strona tego narzędzia, a na niej filmik prezentujący sposób pracy z nim (polecam go obejrzeć, to co opiszę dalej w dużym stopniu opera się o to co zostało tam pokazane). Używanie tego wymaga pewnego zachodu z ustawieniem środowiska pracy, tak aby testować kod we wskazanych przeglądarkach.
Tutaj jest dobre miejsce do startu, są tu przykładowe testy wraz ze wszystkim co jest potrzebne do uruchomienia, Potrzebne pliki (jary) można jednak pobrać z innego miejsca. Także idąc za podanym przykładem, testy będę pisał w oparciu o ten sam problem „gra w życie” (szczegóły).
Jak uruchomić serwer testów
A więc zaczynajmy od uruchomienia serwera, należy mieć odpowiedni jar (tutaj jest to JsTestDriver-1.3.5.jar). Serwer można uruchomić poniższą komendą:
java -jar JsTestDriver-1.3.5.jar --port 9876
Lub za pomocą skryptu, zawierającą tą komendę. Jest to najprostsza konfiguracja gdzie jedynym istotnym parametrem jest port pod którym będzie dostępny serwer. Po wystartowaniu serwera należy otworzyć przeglądarkę, w której chce się testować (można testować jednocześnie pod kilkoma), i podać adres:
http://localhost:9876
Następnie kliknąć link „Capture This Browser” i przeglądarka jest przechwycona do testów.
Jak uruchomić testy
Testy uruchamia się podobną komendą, choć jest ona trochę bardziej skomplikowana. U mnie upchnięta do pliku bat wygląda tak:
set BASE_DIR=D:\game-of-life
java -jar "%BASE_DIR%\JsTestDriver-1.3.5.jar" ^
--config "%BASE_DIR%\jsTestDriver.conf" ^
--basePath "%BASE_DIR%" ^
--tests all --reset
W podanym przykładzie wszystkie pliki są w tym samym katalogu. Plik jsTestDriver.conf z konfiguracją mówiący o tym co ma być wczytane podczas uruchamiania testów i pod jakim adresem działa serwer testów. Wygląda on tak:
server: http://localhost:9876
load:
- js/jasmine.js
- js/JasmineAdapter.js
- http://underscorejs.org/underscore-min.js
- game-of-life.js
- game-of-life-tests.js
Kończąc ten opis jak uruchomić testy.
Całość kodu jest dostępna tutaj. A sama symulacja życia może być podziwiana tutaj. Fajny sposób do dzielenia się kawałkami kodu ;). Można na żywo edytować i sprawdzać jak zmiany się zachowują. Polecam pobawić się zmianą reguł życia.
Dysonans poznawczy
Dysonans poznawczy to ciekawy termin na który ostatnio wpadłem. Link jest lepszym źródłem wiedzy, więc dalej przytoczę do czego może wydawać się to użyteczne.
Wyrywkowo jednak aby skupić się na tym o co mi chodzi to: „Teoria dysonansu poznawczego postuluje, że gdy w sytuacji wolnego wyboru postępujemy niezgodnie z naszymi postawami, to postawy zostaną dostosowane do naszych zachowań. Ludzie myślą tak, aby to było zgodne z ich zachowaniem”. Lub inaczej człowiek stara się redukować stany w którym odczuwa że „Co innego myślę, a co innego robię”.
A co do wykorzystania tego. W oparciu o założenia tej teorii był wykonany eksperyment, w skrócie było to tak: Poproszono studentów o wzięcie udział w pogadance dla liceistów na temat korzyści z używania prezerwatyw. Później stwierdzono że wśród tych studentów wzrost poziom użycia prezerwatyw.
Tak więc przeszczepiając to na grunt informatyczny: jeśli ktoś wystąpi z prezentacją w której mówi na przykład o zaletach stosowania TDD, podczas gdy nie do końca jest o tym przekonany, to może to skutkować tym że w późniejszym okresie będzie częściej stosować tą technikę ;). Tak jakby tłumaczył się, że w końcu zachwalałem to publicznie, to trudniej jest mu postępować inaczej później. Takie zachowanie wprowadzające dysonans nie musi sprowadzać się do prezentacji, może to być wpis na blogu lub podpisanie ankiety popierającej coś (na przykład w takiej formie).
W każdym razie przy pomocy takiego triku można chyba promować zachowania, które się pożąda, jeśli inne wydawałoby się racjonalne argumenty zawiodły ;).
Małe narzędzie do przetwarzania plików
Przetwarzanie plików, ich zawartość, tak aby na ich podstawie stworzyć coś innego.
Najczęściej jeśli pliki są niewielkie robi się to ręcznie. Jeśli są trochę większe to można zaprzęgnąć do tego jakieś dobry edytor tekstu. A czasem trzeba napisać narzędzie do tego.
Poniżej zamieszczam prosty skrypt do przetwarzania plików, będzie służył jako baza do tworzenia podobnych narzędzi w przyszłości.
print "start"
class Paczka:
tabela = ''
nazwa = ''
kolumna = ''
def build(self):
return 'CREATE INDEX '+self.nazwa+' ON '+self.tabela+' ('+self.kolumna+');'
file = open('indeksy.txt','r+')
data = file.readlines()
file.close()
paczka = Paczka()
for line in data:
if ("Foreign Key:" in line):
paczka.nazwa = line.split("Foreign Key:")[1].strip()
if ("On Table:" in line):
paczka.tabela = line.split("On Table:")[1].strip()
if ("Columns:" in line):
paczka.kolumna = line.split("Columns:")[1].strip()
if ("Columns:" in line):
print paczka.build()
paczka = Paczka()
print "koniec"
Jak można wyczytać program ma wyprodukować zbiór instrukcji tworzących indeksy. Robi to na podstawie pliku, zawierającego wskazania w których miejscach można poprawienia wydajności bazy. Przykład poniżej:
! Foreign Key: SCHEMAT.FK_TABELA_1 ! On Table: TABELA_1 ! Columns: KOLUMNA_1 ! Foreign Key: SCHEMAT.FK_TABELA_2 ! On Table: TABELA_2 ! Columns: KOLUMNA_3 ! Foreign Key: SCHEMAT.FK_TABELA_3 ! On Table: TABELA_3 ! Columns: KOLUMNA_3
Program jest prosty, widać co jest robione. Usprawnienie co do pierwotnej wersji to wydzielenie klasy agregującej dane. Daje to odseparowanie togo co ma powstać od etapu przetwarzania pliku. Można by się pokusić jeszcze o uogólnienie kodu przetwarzającego poszczególne linie (pozbycie się if_ów). Jednak w tym przypadku byłby to już przerost formy nad tym co ma być wykonane. Może kiedyś uaktualni się ten wpis.
Cargo cult programming
Ostatnio parokrotnie trafiłem na pojęcie kultu cargo, co w końcu doprowadziło mnie do Cargo cult programming. I to właściwie wszytko :). Takie zgrabne pojęcie, a tyle oddaję.
Ze swojego podwórka. Pamiętam jak we wczesnej wersji Springa, kiedy wymagane było tworzenie interfejsów do beanów dla których chciało się tworzyć proxy (było to na potrzeby tworzenia mechanizmu transakcji). I tu bezrefleksyjnie klepane były wszystkie klasy z interfejsami, i w wielu przypadkach nigdy nie korzystało się później z możliwości jakie dawały te interfejsy ;). Tak w mądrych przykładach było, więc pewnie powinno być tak. I sam później jeszcze przekazywałem innym, że tak należy robić:).
Pewnie każdy ma skłonności do takiego postępowania, nie tylko w dziedzinie programowania.
A tu trochę linków do samego tematu. To jest chyba pierwsze ujęcia tego tematu, a tu jest wpis po polsku, zawiera także odnośnik do tłumaczenie pierwszego linku.
Proxy w JavaScript
Trafiłem ostatnio na ciekawe użycie Proxy w JavaScript. Wcześniej nie myślałem że można tak robić. Pisałem (pisze ciągle) bardziej w skryptowy (proceduralny) sposób w tym języku. Jednak JavaScript jest bardziej elegancki w wyrażaniu intencji jakie kryją się za pojęciem proxy.
A więc w kodzie wygląda to tak, prosta funkcja i następna która tworzy proxy do pierwszej:
function executeAlert(){
alert('powiedz w alert');
}
function decorateExecuteAlert(){
var oldExecuteAlert = executeAlert;
executeAlert = function() {
alert('przed alert');
oldExecuteAlert();
};
}
Albo jeszcze lepiej można zmienić samego alerta:
function changeAlert(){
var oldAlert = alert;
alert = function(value) {
oldAlert('>'+value+'<');
};
}
Jak już zasugerowałem to nazwą drugiej funkcji, jest to też rodzaj dekoratora. Ogólnie taka konstrukcja oferuje duże możliwości. Ja na nią trafiłem idąc za potrzebą stworzenia obserwatora zdarzeń wywołania danej funkcji. Dzięki temu można czasowo dodać (podpiąć się) coś do danej funkcji, a potem usunąć to. Można też zmodyfikować działanie i dodać warunek kiedy właściwa funkcja ma się wykonywać, lub podpiąć dodatkowe logowanie do wywołań jej. Możliwości jest wiele :).
Błędy związane z czasem
Nazbierało mi się ostatnio trochę ciekawych przypadków/błędów związanych z czasem. Są one trochę inne niż te które zazwyczaj spotykam. Mają one tą szczególną cechę że pojawiają się naglę, mimo że nic się w strukturze kodu nie zmieniło; lub występują, a potem znikają (duch).
Przytoczone tu przypadki są związane z bazą danych (może lista się rozszerzy z czasem, a może ktoś podrzuci inne przykłady). Są to błędy związane raczej z danymi, stąd może dlatego częściej pojawiają się właśnie przy bazie.
Przypadek przeterminowania się danych
Objawy: Coś nagle przestało działać, a nic nie było ruszane.
Przykład: Sprawdzenie czy dziś nie mija jakaś data. Warunek ten może być zaszyty w jakimś zapytaniu, widoku czy procedurze. Wszystko jest dobrze na początku, gdy owa graniczna data jest odległa w czasie, powiedzmy za rok. Kiedy jednak to nadchodzi, może być zdziwienie, chwila zamieszania i długotrwałe przeszukiwanie całego kodu, a baza często stoi jako jeden z ostatnich etapów tego szukania.
Nie chodzi tu tylko o przypadek zaszycia sprawdzenia czasu z obecną data (SYSDATE), ale może to być jakaś wartość wzięta z bazy, którą ktoś nieopacznie zmienił, a związek z błędem może nie być łatwo dostrzegalny.
Przypadek niewłaściwego formatu czasu
Objawy: Brak działania funkcjonalności w określonych porach.
Przykład: Narzucenie dostępności czegoś w określonych dniach, czy godzinach.
Błędy gdy zegar systemowy rozjedzie się z rzeczywistością. Bardziej prawdopodobne na etapie developmentu – kiedy nie dba się zbytnio o środowisko i nikomu nie przeszkadza że zegar spieszy się przykładowo o 2 godziny.
Określenie dnia tygodnia (ten właśnie przypadek natchną mnie do napisania tego posta 😉 ). Nie właściwa instalacja bazy i przyjęcie formatu daty, lokalizacji serwera w innej strefie czasowej. A to może prowadzić, że na jednej instancji bazy funkcja może zwracać inne wartości niż na drugiej. Ów przykład dla Oracla
TO_CHAR (SYSDATE, 'D')
określenia jaki dzień tygodnia mam – raz może się to liczyć od niedzieli, innym razem od poniedziałku.
Samolubny kod
Samolubny kod czy klasa. Początek tutaj, a reszta jest luźnym komentarzem do tego.
Jest to ciekawe przedstawienie życia kodu w ujęciu teorii próbującej objaśnić szerzenie się idei (jak w skrócie można potraktować to co się kryje za słowem mem).
Sama teoria (jak dla mnie) wydaję się dość abstrakcyjna, jednak próba pokazania jej przez pryzmat tworzenia kodu daje fajne przemyślenia. Można spróbować wyciągnąć jakieś wnioski, zastanowić się dlaczego niektóre, wydawałoby się, wartościowe kawałki kodu nie cieszą się uznaniem. Podczas gdy inne, pośredniej jakości, są aż nadto rozpowszechnione. „Kawałek kodu” nie jest tu tylko dosłownie paroma linijkami kodu, ale może być to także biblioteka, aplikacja czy sposób pisania go.
Tak ujęty temat, może być pomocny w naszym codziennym kodowaniu. Poprzez szukanie odpowiedzi na pytania typu: Jak sprawić aby niektóre rozwiązania łatwiej infekowały nieświadomych tego programistów ;-), podczas gdy inne były wypierane?. Albo co trzeba zrobić aby biblioteka, którą tworzymy, trafiła pod „strzechy” (lub odwracając: którą bibliotekę wybrać do nauki, aby nie zmarnować zainwestowanego w nią czasu).
Może powiedzieć, że są to rady powtarzane gdzie indziej. Jednak pozwala to jeszcze raz spojrzeć na nie, w trochę inny sposób, i tym samym łatwiej jej zapamiętać (pozwolić się szerzyć nim :D). Na koniec przewrotne stwierdzenie. Każdy pewnie chciałby żeby jego kod miał szanse przeżyć, rozmnożyć się i stać się tak popularny jak „kopiuj-wklej”. A zapewne jest o wiele więcej naszego kodu, któremu nie chcielibyśmy dać takiej możliwości :D.
Przedwczesna optymalizacja
Pojęcie przedwczesnej optymalizacji … zastanowienie się nad tym ;).
Uderzyło mnie to przy próbie pisania w pl/sql. Poczułem się w tym na tyle swobodnie, że zacząłem tworzyć już z myślą o wydajności, wtedy kiedy jeszcze głównych założeń algorytmu nie miałem do końca uchwyconych. I straciłem pół dnia na roztrząsanie technicznych szczegółów (i to jeszcze na siłę próbowałem zrobić to sam, gdy mogłem zapytać o pomoc).
Zbyt szybko chciałem iść na skróty, kiedy musiałem poruszać się po omacku.
Lepiej jest więc napisać coś co już na starcie nie musi być optymalne, aby mieć przynajmniej pewność, że działa. Najpierw niech działa (zostanie zrozumiałe), potem może być udoskonalanie.
To znaczy: podążanie za przeczuciem do idealnego rozwiązania jest dobre kiedy umiesz się poruszać sprawnie w danym środowisku. W innym wypadku lepiej jest uważać na każdy krok (nie pomijać go). I liczy się z tym, że w pierwszej kolejności stwierdzenie „działa”, jest głównym wyznacznikiem tego że zmierzamy do celu.
Czytaj dalej…
Poszukiwanie narzedzia
Na początku była potrzeba tworzenia dokumentacji, zostało to opisane tutaj. Miało to jednak dalszą kontynuacje.
Wraz z przejściem do projektu (trwał on już od jakiegoś czasu) stanąłem przed wyzwaniem zapoznania się z bazą danych (jedną z wielu). Dokładniej miałem do rozpoznania jej wycinek, aby przygotować kilka zapytania. I tu okazało się, że to co kiedyś stworzyłem w innym projekcie na potrzeby klienta/administratora może być teraz pomocne dla mnie. Było to sposób produkcji dokumentu przedstawiającego relacje pomiędzy tabelami w bazie. W zamierzeniu miała to być pomoc do zaznajomienia się z baza, w sam raz na początek, gdy obraz jej nie jest jeszcze utrwalony w głowie. Czytaj dalej…
Link – software craftsmanship
Link na który trafiłem podczas przerwy (obijania się) w pracy.
Jest to o coraz bardziej modnym słowie „software craftsmanship”.
Mam opory do wygłaszania tu jakichś ostrych opinii, nie wiem czy w ogóle jest potrzeba.
Zostawiam ślad w postaci tego linku i paru szybkich wrażeń, może ciekawie będzie spojrzeć na to za jakiś czas.
W wywiadzie podobało mi się to: Jeśli w danym momencie nie wyrabiasz się, nie masz czasu, czy zdolności, aby pracować w taki sposób jaki byś chciał (na poziomie jaki byś chciał), to OK!. Świat się nie wali. Rejestrujesz ten fakt i w przyszłości, kiedy czas pozwoli starasz się spróbować znaleźć sposób, aby móc zbliżyć się choć trochę bardziej do tego poziomu.
Jest to wola postarania się, aby znaleźć sposób na zmniejszenie tej przestrzenie jaka jest pomiędzy stanem obecnym, a tym jaki chciałbyś osiągnąć. I nie chodzi o to, żeby następnym razem zrobić coś doskonale. Sukcesem będzie już to, jeśli będzie to choć odrobinę lepiej zrobione niż poprzednim razem.
I na koniec hasło przewodnie: zdobycie umiejętności trwa ;).
Miała być Java 