Najgorsze problemy ever

Pamiętam jak dawnymi czasami każde exception przyprawiało mnie o gęsią skórkę. Szukałem sposobu jak tu je wyeliminować (choć już wtedy wiedziałem, że niektórych wyjątków nie wyeliminuje nigdy). Dziś z perspektywy czasu wiem jaki byłem głupi. Czasami exception to rzecz, o której wprost marzymy. A jak to z marzeniami bywa rzadko się one spełniają.
Kilka “ciekawszych” problemów z którymi się zetknąłem:

1. Backup bazy danych działa wybiórczo

Wdrażając oprogramowanie u klienta liczyłem tylko na jedno niech mają kogoś kto zarządza ich siecią i choć trochę się na tym zna. Gdy słyszałem pytanie jak wygląda kwestia robienia backupu bazy to wiem, że źle nie trafiłem. Niestety zdarzały się organizację, które z powodów “oszczędnościowych” nie posiadały odpowiednich fachowców. Pamiętam, że w takich przypadkach przygotowałem prostą rzecz – tworzenie kopii bazy danych przy wyjściu z programu. Mało eleganckie, ale skuteczne i działające. Tylko, że z tym działaniem był pewien problem. Nie wiedząc czemu na niektórych komputerach to nie działało. Tzn. skrypt się odpalał i tworzył w określonej lokalizacji plik backupu. Tylko, że ten plik był pusty. Logi nie wykazywały niczego podejrzanego, program nie rzucał błędami a mimo to plik generował się pusty. Rozwiązanie: robiąc backup za pomocą pg_dump należało w pg_adminie zaznaczyć “Zapamiętaj hasło”.

2. Nie można otworzyć programu hasłem … ale tylko na jednym komputerze

Są takie aplikacje, które wymagają hasła przed wejściem i jest to całkowicie zrozumiałe. Co jednak w sytuacji gdy użytkownik nie może zalogować się swoim hasłem. Pewnie go zapomniał i należy je zresetować tylko, że na drugim stanowisku ono działa. Pierwsza myśl CapsLock okazuje się błędna. Hasło to ciąg cyfr zapisany na kartce przyklejonej do monitora 🙂 Co gorsza kod aplikacji napisany jest w jakimś starym języku (“no ale jesteś programistą poradzisz sobie”). Co robić? Aplikacja korzysta z jakiejś biblioteki Windowsowej, z której korzysta też .net. Próbuje zrozumieć składnie na szczęście wraca autor programu więc zrozumienie co się po kolei dzieje i jak czytać kod jest dużo łatwiejsze. A rozwiązanie okazuje się proste. Uszkodzeniu uległ profil użytkownika systemu Windows i należy go naprawić (inna sprawa, że według Microsoftu naprawa to utworzenie nowego profilu).

3. Aplikacja działa … ale nie u klienta

Mamy do napisania mały program. Tak mały, że nie potrzebujemy do niego bazy danych. Bo bez sensu mieć bazę danych aby zapisać dziesięć parametrów na krzyż. Zserializujemy do Jsona i będzie git. Jak się potem okazało nie było. Dla uproszczenia powiedzmy, że program miał trzy następujące po sobie okna. W pierwszym ustalamy ścieżki do folderów, z których ma zaczytywać dane (wskazywane z wykorzystaniem FolderBrowserDialog), w drugim wskazujemy konkretny plik do obróbki (wskazywany z wykorzystaniem OpenFileDialog) a w trzecim parametry. Na danych, które otrzymaliśmy chodziło dobrze. Na tych samych danych u klienta były problemy. Trzecie okno z listą parametrów było nieuzupełnione a także program nie znajdował ścieżek z pierwszego okna(pomimo, że po wejściu do programu były one ustawione i były poprawne) – czyli nic nie robił. Przyczyna? OpenFileDialog+Windows Xp. Po wybraniu pliku do obróbki program szukał naszych Jsonów w właśnie tym folderze. A rozwiązanie:

var dialog = new OpenFileDialog
{
    AutoUpgradeEnabled = true,
    RestoreDirectory = true,
};

4. Sterownik do drukarki fiskalnej … jest dziwny

Miałem kiedyś okazję napisać prosty wrapper łączący drukarkę fiskalną z programem, nad którym kiedyś pracowałem (a teraz robię już tylko jakieś poprawki). Przeglądając API sterownika uwagę przykuła jedna rzecz: nigdzie nie mogłem znaleźć żadnych exception ani żadnych kodów błędów. W tym momencie zapaliła mi się lampka ostrzegawcza. Lampka zaczęła mrugać gdy zobaczyłem, że praktycznie każda (95%) metoda zwraca boola. Czyli teoretycznie mógłbym otworzyć połączenie z drukarką a następnie drukować paragon tylko, że muszę sprawdzić czy otwarcie połączenia zwróciło true oraz czy wydruk pozycji zwrócił również true. Niefajnie. A jeszcze ciekawiej zrobiło się gdy okazało się, że muszę przesyłać również podsumowania pozycji (to nic trudnego bo co to za problem sumować sobie wartości poszczególnych pozycji) mimo tego, że drukarka zna wartość podsumowania bo wprowadzając złe wartości jako sumę metoda zwraca false. Czyli miałem spełnione moje marzenia z początków mojej kariery a mimo to byłem nieszczęśliwy. No cóż nikt nie powiedział, że będzie łatwo(jak powiedział to znaczy, że kłamał).

5. Raport generuje się przeraźliwie wolno

To akurat najnowszy rodzynek. Do przygotowania był mały raport. Jak zwykle wykorzystaliśmy to co znaliśmy czyli Crystal Reports. Do raportu przekazywany jest DataSet z kilkunastoma polami(jeden wiersz dla dokładności). Dodatkowo w ramach raportu było kilka sumowań. Ponadto przekazujemy jeden parametr – wielkość czcionki. Tylko, że raport generował się około minuty(!!) a to stanowczo za dużo. Co więc począć? Zakasać rękawy i zrobić Code Rewiev. Pierwsza myśl jakiś problem z generowaniem danych. Inne potencjalne możliwości wydają się równie bzdurne. Sprawdzamy je więc po kolei. Dane generują się w ułamku sekundy. Na output nie jest rzucany żaden wyjątek. Pozbycie się sumowań z raportu nic nie dało tak samo jak pozbycie się parametru służącego ustawieniu wielkości czcionki jak i eksperymenty z różnym położeniem wyświetlanych danych w obrębie raportu (nagłówek strony, nagłówek raportu, szczegóły, stopka raportu, stopka strony). W końcu nawet usunięte zostały dane i została sama tabelka. Raport dalej odpalał się minutę. Zdesperowani doszliśmy do wniosku, że plik rpt został uszkodzony i trzeba to robić od nowa. Szybko poprzeciągaliśmy dane które chcemy wyświetlić (na razie bez ładu i składu). Teraz raport odpalał się w błyskawicznie. Jest sukces. Teraz tylko ustawić dane w formę tabelki (wzór przesłany przez klienta w pliku pdf) i … raport znów odpala się minutę. Usuwamy tabele, sekunda przywracamy tabele wraz z etykietami (labelami) minuta. WTF?? Usuwamy labele znów sekunda. No ale jak głupi label może tak spowolnić maszynę? Otóż wystarczyło aby czcionka w pdf była nierozpoznawana przez CrystalReports a były to skomplikowane opisy i chcąc uniknąć literówek kopiowaliśmy je z pdfa. Zmiana na Arial (z ArialMT) podziałała jak ręką odjął. Wszystko chodzi jak błyskawica (inną rzeczą pozostaje, że przy najbliższej okazji spróbuje inny sposób tworzenia raportów bo ten ewidentnie nie lubi naszego teamu).

Podsumowanie

Na przyszłość gdy ci nic nie wychodzi, gdy aplikacja wyrzuca jedno exception po drugim pomyśl, że mogłeś mieć gorzej. Mogłeś mieć aplikację nie rzucającą żadnych błędów, a mimo to działającą źle. Pomyśl, że ktoś w tej chwili tak ma (tylko dlaczego to zawsze jestem ja?).

2 thoughts on “Najgorsze problemy ever

  1. Pingback: dotnetomaniak.pl
  2. Oj, nieprawda. Ja głównie naprawiam błędy w sporej aplikacji ERP. Brak błędu, złe działanie, i wina kontrolek to podstawa 🙂

    Swoją droga do raportowania fajny jest aspx -> html, a potem html -wkhtmltopdf-> pdf.

    Paweł

Comments are closed.