Problem z Resharper 7.1 i VS 2012 Update 4

Home

Od czasu sławetnej promocji JetBrains jestem szczęśliwym posiadaczem Resharper'a 7.1 Nie będę pisał, że to bardzo dobre narzędzie bo o tym chyba już każdy wie. Niestety jakiś czas temu przestała mi działać opcja Run Unit Tests w Visual Studio 2012 tj. po jej wybraniu testy nie były poprostu uruchamiane. Problem zbiegł się z instalacją Visual Studio Update 4, a więc miałem podejrzenie, że w tym tkwi problem. Ostatnio natknąłem się na ten wątek i okazało się, że miałem rację. Szczęśliwie zainstalowanie najnowszej wersji Resharper'a 7.1 rozwiązało problem.

"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.