Staczam się… ;-)

Chyba się staczam… ostatnio zarywam noce kodując w… PHP. ;-)

Wszystko dlatego, że postanowiłem u siebie postawić
system śledzenia błędów dla PLD. Stary był brzydki i
niezbyt wygodny, a przez ostatnie tygodnie nie działał w ogóle — zbytnio
obciążał maszynę na której był postawiony, a poprawiać go nie było komu.

Dyskusja na temat alternatywy powracała już kilka razy na listy zwykle bez
efektu. Jednak pewną tendencję w dyskusjach można było zauważyć — nowy
system powinien być opary o jakieś gotowe rozwiązanie, najlepiej żeby to była
Bugzilla, Mantis lub Flyspray. Bugzilla mi się nie podoba (stanowczo za dużo
kontrolek w formularzach), poza tym wydaje się na tyle skomplikowana, że jej
dostosowanie do naszych potrzeb mogłoby okazać się trudne i długotrwałem.
Mantisa nie znam, a Flyspray, znany
z Buggera po prostu mi się podoba,
a skoro ja użyczam sprzętu i chcę sie tym zająć, to moje zdanie może być
decydujące. :-)

Tak po prostu postawić Flyspray’a to byłoby za mało. On powstał dla
zupełnie innych projektów niż PLD. Np. pole system operacyjny nie ma
u nas sensu, zamiast tego ważniejsza jest architektura. Poza tym w błędzie
najistotniejszy jest pakiet którego dotyczy i jego wersja. Nie chciałem dla
każdego pakietu robić osobnego projektu (osobne projekty są dla poszczególnych
linii dystrybucji (Ra, Ac, Th) i innych projektów związanych z PLD (ten BTS,
LiveCD, RescueCD)), więc wykorzystałem obecne już pole kategoria.
Trzeba było przy tym mocno zmienić interfejs, gdyż pole wyboru pakietu
zawierające listę wszystkich pakietów (tysiące!) to byłoby nieużywalne.
Podobnie z wersjami, które w oryginalnym Flyspray są określane per-projekt,
a u nas muszą być per-pakiet. To wszystko udało się właściwie zrobić.
Udało mi się też przenieść bazę pluskiew ze starego systemu.

Poza zmianami przystosowawczymi wprowadziłem też inne ulepszenia.
Np. język interfejsu jest konfigurowalny per-użytkownik, a domyślnie brany
z ustawień przeglądarki. Poza tym włączyłem serwowanie stron jak
application/xhtml+xml dla przeglądarek które to akceptują. To
zresztą uziemiło system na jakiś czas, bo się okazało, że XHTML to strony
generowane przez Flyspraya mają tylko w DOCTYPE. No na głównej stronie nie
było źle, nie walidowała się jedynie z powodu pustego <optgroup/>.
Niestety większość pozostałych stron nie była nawet well-formed XML
przez co przestała się w ogóle wyświetlać. Wczoraj udało mi się większość
z tego poprawić, więc już się wyświetla w przeglądarkach obsługujących XML,
ale raczej Valid XHTML Strict to w większości nie jest.

No i dzisiaj wreszcie udało mi się uruchomić narzędzie, które w poprawianiu
tego XHTMLa może mi pomóc:
HTML Validator dla Mozilli
. Polecam! Niestety to rozszerzenie w postaci
gotowej do zainstalowania dostępne jest jest jedynie dla Windowsów.
W Linuksowym Firefoksie instaluje się bez zająknięcia, ale po prostu nie
działa. Okazało się, że w środku siedzi binarka nstidy.dll,
nstidy.so trzeba sobie samemu skompilować (źródła rozszerzenia są
dostępne). Do kompilacji teoretycznie potrzebne są źródła Mozilli, ale nie
uśmiechało mi się ich instalowanie i kompilowanie, więc jakoś poradziłem sobie
bez tego — w końcu hacker jestem! ;-)

Poza BTSem podłubałem trochę w automatyce builderów (małe zlecenie do
Havnera). To już była czysta przyjemność, bo automatyka jest w Pythonie.
:-) Niestety okazało się, że przy okazji coś po psułem
i w niedzielę w nocy, zamiast iść spać musiałem poprawiać…

5 uwag do wpisu “Staczam się… ;-)

  1. Patrys: tak 😉

    U nas w dziale oprogramowania też robią wszystko w PHP, ale mimo to uważają, że to głupota. Tyle, że już za późno żeby się wycofać. A ten który się przy tym PHP upierał już tam nie pracuje, bo kiepski z niego był programista…

    Polubienie

Co o tym sądzisz?

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s