Mała wskazówka jak pisać szybsze makra dla Excela

Home

Od dłuższego czasu do śledzenie rodzinnych wydatków używam programu Excel wraz z napisanym przez siebie makrem, które wylicza statystyki, sumuje wydatki według kategorii itp. Po przesiadce na nowy komputer makro zaczęło jednak działać wolniej. Wcześniej przeliczenie arkusza zajmowało chwilę, a teraz nawet kilka sekund. Dodatkowo w czasie działania makra arkusz migał. Ewidentnie wygląda to na problemy z szybkim odświeżaniem ekranu. Może spowodował to nowy system operacyjny, a może nowy sterownik karty graficznej?

Nie wiem jaka dokładnie była przyczyna ale rozwiązanie problemy było bardzo proste. Postanowiłem poszukać Excel'owego odpowiednika metod SuspendLayout/ResumeLayout znanych z technologii Windows Forms. Bardzo szybko znalazłem właściwość Application.ScreenUpdating, która pozwala włączyć/wyłączyć odświeżanie ekranu. Jej ustawienie na False w makrze przed rozpoczęciem obliczeń, a potem znowu na True rozwiązało mój problem w 100%.

Filtrowanie work item'ów

Home

Sądzę, że do wyszukiwania work item'ów z poziomu Visual Studio najczęściej stosowane jest zapytanie typu Flat List. Zasada użycia jest bardzo prosta, po prostu podajemy zestaw warunków na podstawie, których chcemy przefiltrować WI np.:

zwróć mi WI typu bug, w projekcie X

W wielu wypadkach to wystarcza, ale ten typ zapytania ma jedno zasadnicze ograniczenie, nie uwzględnia relacji pomiędzy WI.

W tej sytuacji z pomocą przychodzą dwa pozostałe, mniej znane, typy zapytań czyli: Tree of Work Items oraz Work Items and Direct Links. Pierwsze pozwala do zapytania dodać warunki na powiązane WI (ale tylko te powiązane relacją rodzic-dziecko) np.:

zwróć mi WI typu bug, w projekcie X
+
oraz powiązane z nimi WI przypisane do osoby Z

Drugi z wymienionych typów, ma takie same możliwości, plus dodatkowo pozwala filtrować powiązane WI na podstawie rodzaju powiązania np.:

zwróć mi WI typu bug, w projekcie X
+
oraz powiązane z nimi, relacją Affected By, WI przypisane do osoby Z

To daje już dużo większe możliwości, ale niestety w ten sposób możemy badać tylko jeden poziom hierarchii WI. Twórcy Team Explorer'a mają się więc gdzie wykazać.

Długość hasła do konta Microsoft

Home

Niektóre decyzje giganta z Redmond podobają mi się, inne mniej, a niektóre w ogóle. Pół biedy kiedy kryje się za tym jakaś logika, ale niektórych rzeczy po prostu nie mogę zrozumieć. Ostatnio chciałem zmienić swoje hasło do konta Microsoft i niezmiernie się zdziwiłem kiedy okazało się, że moje hasło jest za długie gdyż miało więcej niż 16 znaków. WTF! W ogólności to nie nowa rzecz ale ja spotkałem się z nią pierwszy razo.

Na tym jednak nie koniec. Jakiś czas potem natknąłem się na to wytłumaczenie. Okazuje się, że hasła zawsze były ograniczone do 16 znaków, a jeśli wprowadzono dłuższy ciąg znaków to było to ignorowane. Teraz zamiast wydłużyć maksymalną dopuszczalną długość postanowiono nie pozwolić na wprowadzenie zbyt długich haseł, bo i po co użytkownik ma się męczyć i nadwyrężać pamięć.

Osobiście nie widzę żadnego "pozytywnego" argumentu za takim limitem na długość hasła. "negatywnym"  i moim zdaniem dość prawdopodobnym  argumentem może być to, że ileś lat temu podjęto błędną decyzję i odkręcenie tego teraz jest trudne i kosztowne.

Oczywiście Microsoft nie jest jedyną firmą, która narzuca "dziwne" ograniczenia na hasła. Tym niemniej jako firma o zasięgu globalnym, mająca setki milionów użytkowników, wypuszczająca rożnego rodzaju rekomendacje dotyczące bezpieczeństwa...  powinna zająć się również takimi podstawowymi rzeczami.

Liczba błędów/KLOC

Home

KLOC (ang. Kilo Lines Of Code) to bardzo stara miara złożoności programów na podstawie liczby linii kodu. Z pewnością ma wiele wad, bo jak porównywać kod w C/C++ z kodem w Java czy C#. Czy jako linie kody powinno liczyć się komentarze lub importy przestrzeni nazw, co z kodem generowanym automatycznie itd. Wszystko to prawda, ale osobiście uważam, że ta miara jednak coś mówi. Ostatnio natknąłem się na bardzo ciekawe dane dotyczące liczby błędów/KLOC.

W książce Code Complete Steve McConnell pisze, że średnia wynosi 15-50 błędów/KLOC dla produkcyjnego kodu (jak dla mnie dużo), a Microsoft osiąga podobno wynik 0.5 błędów na tysiąc linii produkcyjnego kodu. W publikacji Number of faults per line of code Myron Lipow cytuje zbliżone wyniki, czyli 5 do 30 błędów/KLOC. Metoda Cleanroom software engineering opracowana przez IBM pozwoliła osiągnąć w niektórych projektach dużo lepsze wyniki. W projektach prowadzonych przez NASA osiągnięto natomiast oszałamiający wynik zero błędów na 500 tysięcy linii kodu. Czemu się jednak dziwić. Na stronie The Flight of STS-1 można znaleźć informację, że NASA wydawała 1000$ na wyprodukowanie jednej linii kodu!!!, podczas gdy średnia przemysłowa na tamte czasy to 50$.

Źródła jakie zacytowałem są dość albo nawet bardzo stare. Sądzę jednak, że współczesne systemy są coraz bardziej skomplikowane i nawet pomimo zastosowania nowoczesnych narzędzi i techniki wyniki będą podobne. Według prezentacji ThoughtWorks z 2007 średnia liczba błędów na tysiąc linii kodu to 5 przy średnim koszcie wyprodukowania jednej linii kodu 5$ (wliczając testy, dokumentację itd.). NASA płaci natomiast 850$ za linię aby obniżyć współczynnik do 0.004 błędów/KLOC.

Pracowałem przy projekcie, w którym udało się uzyskać bardzo dobry wynik 0.23 błędów/KLOC przy czym dużo zmian zostało wprowadzonych przez stworzone przez zespół narzędzia do automatycznej modyfikacji kodu. Jestem ciekawy Waszych opinii na temat tej miary? Jaki wynik uważacie za dobry?

Co robię z poufnymi...

Home

Post ten jest częściowo powiązany z poprzednim, w którym napisałem, jak podchodzę do bezpieczeństwa swoich danych. Tym razem opiszę, jak pozbywam się poufnych danych...

Zacznijmy od papierowych dokumentów, które są już nam do niczego potrzebne. Pomimo tego, że staram się ograniczyć ich "produkcję", to trochę się tego zbiera: paragony ze sklepów, rachunki, faktury, stare umowy, wyciągi z banków itd. Przynajmniej na części z nich można znaleźć nasze dane teleadresowe i na przykład powiązać wyciąg z banku z mieszkaniem numer X przy ulicy Y. Może i jestem przewrażliwiony, ale ja takich rzeczy nie wyrzucam do kosza. Już dawno temu sprawiłem sobie niszczarkę firmy Fellowers i wszystkie poufne dokumenty lądują właśnie w niej.

Podejście do poufnych dokumentów rozciąga się również na świat elektroniczny. Kiedy jakiś czas temu miałem problemy z telefonem i musiałem oddać go na gwarancję, usunąłem z niego wszystkie dane. Ponieważ jednak nie byłem pewny gdzie dokładnie trzymane są hasła do mojego konta Google oraz kont pocztowych na wszelki wypadek, przed oddaniem sprzętu do serwisu, zmieniłem hasła. Kiedy wyciekły hasła z portalu LinkedIn, to, pomimo tego sądzę, że moje oparłoby się metodzie słownikowej, a jego złamanie zajęłoby trochę czasu, bez zastanowienia je zmieniłem.

Rok temu chciałem zezłomować stary, niedziałający laptop. Niejeden pewnie wyrzuciłby go do kosza lub oddał to wyznaczonego punktu. I jak tak rozbiłem, ale wcześniej wyciągnąłem z niego dysk. Z jednej strony był jeszcze sprawny, a z drugiej po co ryzykować. Jeszcze nie potrzebowałem tego robić ale gdybym chciał się pozbyć dysku to najpierw użyłbym jakiegoś narzędzia do zamazywania danych (na przykład CCleaner), potem go sformatował, a na koniec uszkodził go fizycznie choćby przy pomocy młotka ;)

Co jeśli chcę usunąć jakieś pojedyncze pliki z dysku? W większości wypadków po prostu je usuwam i opróżniam Kosz, choć ta operacja tak naprawdę nie gwarantuje fizycznego usunięcia danych z dysku. W 99.9% przypadków to mi jednak wystarcza. Kiedy zależy mi na bezpowrotnym wymazania danych postępuję inaczej. Kiedyś korzystałem z opcji Wipe programu PGP. W tej chwili przestawiłem się na GPG, który nie posiada tej funkcji, a więc testuję program shred z pakietu GNU CureUtils. Jeśli nie chce się Wam używać takich narzędzi, to, moim zdaniem, przed usunięciem pliku warto przynajmniej otworzyć i nadpisać jego zawartość.