"Sztuczka" dla pracujących z danymi hierarchicznymi

Home

Pracuję przy projekcie, którego ważnym elementem jest obsługa tzw. profili inwestycyjnych np.:

Fundusz A inwestuje 10% w Fundusz B i 30% w Fundusz C, a Fundusz C 100% w Fundusz D, który...

Pisząc zapytanie wyciągające takie hierarchiczne chcę szybko podejrzeć wynik w formie graficznej. W końcu jeden obraz wart więcej niż tysiąc rekordów zwróconych przez zapytanie. Kolega (dziękuję Łukasz) polecił mi stronkę GraphViz Workspace, która na życzenie generuje grafy/drzewa na podstawie opisu zgodnego z formatem obsługiwanym oczywiście przez Graphviz.

Ok, ale jak to wykorzystać aby łatwo i szybko wizualizować wynik zapytania? Oto prosty przykład. Zacznijmy od utworzenia tabeli z danymi hierarchicznymi.

CREATE TABLE dbo.Hierarchy
(
 Parent INT,
 Child INT
);

INSERT INTO dbo.Hierarchy(Parent, Child)
VALUES (1,2), (1,3), (1,4), (2,5), (2,6), (4,5), (5,7), (7,8), (6,8);

Następnie wyciągniemy z niej dane, bazując na tym, że w formacie GraphViz węzeł rodzic i węzeł dziecko połączone są strzalką ->:

SELECT CAST(Parent AS VARCHAR) + '->' + CAST(Child AS VARCHAR)
FROM dbo.Hierarchy

Wynik zapytanie wystarczy skopiować i umieścić na stronie GraphViz Workspace:

digraph g{TUTAJ}

Aby otrzymać taki wynik:



Prosto, łatwo i przyjemnie.

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?