Visual Studio 2015 i upgrade projektu za każdym razem

Visual Studio 2015 jest już od jakiegoś czasu. Instalacja, odpalenie projektu i do przodu. Coś tam się zaktualizowało w projekcie i mogę dalej pracować z nowymi zabawkami. Problem jaki mi się pojawił to w jednym solution ze sporą ilością projektów jeden z nich aktualizował się przy każdym otwarciu projektu.

Projekt, który chciał się aktualizować przy każdym otwarciu Visual Studio to MVC3, który później był migrowany do MVC4. Przy każdym otwarciu upgrade i kopia wszystkich plików i raport w html-u. Zanim na to zwróciłem uwagę, wrzuciłem całkiem sporo gnoju do repozytorium. Poszukując rozwiązania okazało się, że w trefnym pliku csproj wystarczy usunąć:

<FileUpgradeFlags>40</FileUpgradeFlags>
<UpgradeBackupLocation>Upgrade20</UpgradeBackupLocation>
<OldToolsVersion>4.0</OldToolsVersion>

Pozostało jeszcze wywalenie gnoju z repo i już można pracować jak człowiek.

NDepend 5 czyli narzędzie do prześwietlania kodu

imageWczoraj wyszła nowa wersja NDepend-a, jeszcze ciepła, cieplutka. 5-tka ma dwie rewolucyjne rzeczy, pierwsza to nowe UI, ładniejsze i bardziej “nowoczesne”, druga – i to jest dla mnie killer to dashboard. Zatem po kolej. Mamy nowe logo, które wygląda całkiem całkiem jak na moje średnio wprawne oko. Mamy wygląd czyli nowe menu, graficzki i inne takie. Wprawdzie nie jest to to co daje Visual Studio, to jednak Patrick (autor tego cudownego narzędzia) mówił, że będą dalej nad tym pracować, więc można się spodziewać, że będzie dostępny również temat a’la visual studio 2012/13. Tyle kosmetyki, teraz to co mnie najbardziej urzekło:

image.

image

imageimage

NDepend automatycznie, raz dziennie wykonuje pełną analizę i buduje wykresiki które to w czasie pokazują jak psujemy kod. Genialnie prosta i użyteczna rzecz. Wprawdzie wcześniejsza wersja protrafiła pokazywać diff z poprzednią wersją to jednak nigdy nie miałem serca aby to uruchomić. Tutaj “out of the box” to dostajemy i to działa Uśmiech a ponieważ wykresy aktualizują się automatycznie, to nie wymaga to od nas nic poza codziennym otwarciem projektu w visualu, swoją drogą, będę musiał sprawdzić jak z automatu codziennie pobrać najnowszą wersję z repo i zaktualizować wykresy.

Jest jeszcze jedna rzecz, która mnie urzekła w tej wersji. Odnoszę wrażenie, że zestaw wbudowanych zasad jest bardziej dostosowany do “Martinowskich” nauczań i tego o czym pisze Robert C. Martin w Clean Code. Oto moja lista warning-ów – i 3 krytycznych naruszeń, jak dla mnie bomba.

image

W ramach promocji, można teraz kupić NDependa z 20% zniżką. Więc jeśli nie masz tego narzędzia to może warto pomyśleć. Myślę, że każdy zespół powinien mieć przynajmniej jedną licencję bo narzędzie daje świetny ogląd na to co tam w kodzie natworzyliśmy.

SSD dla developera czyli Samsung 840

samsung-840-pro.jpg

Długo się zastanawiałem czy przejść na SSD czy nie. Z jednej strony internety mówią, że to takie super i szybkie i w ogóle a z drugiej cena jakoś ciągle jeszcze nie jest przyzwoita, szczególnie że 128GB to dla mnie za mało – potrzebuję ~200GB. W końcu jednak stwierdziłem, że trzeba spróbować. Wybór padł na Samsung-a 840 Pro. Podstawowy argument to 5 lat gwarancji, drugi to (podobno) najszybszy dysk na rynku. Jak inwestować to w najlepsze zatem zakupiłem. Pierwsze wrażenia, piękne pudełko i piękny dysk. Mimo, że to nie ma wielkiego znaczenia to jednak robi wrażenie czarne pudełko z lekką, błyszczącą fazą. Dla porównania stary dysk, który to cudo zastępuje to ordynarna blacha z wielkimi śrubami na górze i stadem nalepek z jeszcze większą liczbą piktogramków, kodów paskowych, QRów i innych bzdetów. Ja wiem, że geeki takie rzeczy lubią ale mimo wszystko dlaczego w środku wszystko musi wyglądać jakby wyrzygał się wielki elektronik?

Jak dysk sobie radzi. Poniżej test dysku. Nie są to syntetyczne testy prędkości bo te znajdziesz wszędzie. Ja po prosty zmierzyłem zwykłym zegarkiem czas uruchomienia tego co używam najczęściej.

operacja

stary dysk

sdd (migracja)

czysta instalacja

restart

1 min 25.74

52.00

15

VS2012

10.82

8.40

2.7

VS2012 projekt testowy

33.38

17

13.90

WebStorm I

56.90

9.2

5.03

WebStorm II

6.55

6

4.6

VS2012 kompilacja projektu testowego

6.21

6.20

6.01

R# Code Issues

25.20

23

18.12

Pierwsza kolumna to stary dysk. Na warsztat poszły VS2012 (z R# 8 EAP + NCrunch-em) i  WebStorm. System to fabrycznie zainstalowany Win7 po upgradzie do Windows 8 Pro.

Druga kolumna to zmigrowany stary dysk na ssd za pomocą narzędzia dostarczanego przez Samsunga. I tutaj już widać olbrzymi skok. Cały system chodził wyraźnie szybciej niż na starym dysku – czyli bajki o szybkości ssd nie są wyssane z palca.

Trzecia kolumna to wyczyszczony SSD i zainstalowany na czystko Windows 8 Pro. I tutaj okazało się, że to chodzi jeszcze szybciej. Kopiowanie danych po ssd i usuwanie jest wręcz nieprzyzwoite pliki po prostu znikają. Chrome uruchamia się tak szybko, że nie ma co mierzyć. Word i Excel to samo. Po prostu się pojawiają – niesamowite.

Jeśli chodzi o Visual Studio to odnoszę wrażenie, że chodzi szybciej. W XAML-ach nie muli się jak w błotnej kąpieli. Co do kompilacji to niestety tutaj wielkiego zysku nie ma – no ale co się dziwić, tutaj trzeba procesora i to nawet nie rdzeni a jednego mega mocnego rdzenia. Swoją drogą to czekam aż Microsoft przepisze kompilator na wielowątkowość, przecież specyfikacja tego nie zabrania.

WebStorm I i II różni się tym, że I to pierwsze uruchomienie a II to każde następne. Przy pierwszym startuje dodatkowo Java więc różnica w czasach jest usprawiedliwiona.

Co do samej “testowej” platformy to jest to zwykły półkowy laptop Dell z i5 (2gen) + 4GB Ramu. Skok wydajności imho jest dużo większy niż gdyby zwiększyć Ramu do 16 (moje max) więc wydaje się, że inwestycja w ssd da dużo lepsze wyniki niż w ram jeśli mamy ograniczone zasoby.

A teraz wady. Dysk ma 7mm  wysokości a w tym konkretnym Dell-u dysk wpina się po prostu w port i tyle, “Pam rest” przytrzymuje go na miejscu dlatego  ta brakująca grubość powoduje, że dysk lata  i obija się. Tutaj z pomocą przyszła szara pianka z jakiegoś pudła. To co dla ultrabooków jest zaletą u mnie okazało się wadą.

Na tą chwilę, mogę polecić taki dysk każdemu. Komputer dostaje skrzydeł i aż chce się pracować. Jak z czasem będzie się sprawdzał? Zobaczymy.

Kodzić po ludzku czyli jak się pozbyć svn-a

Git jest git jak mawia Spartakus Maciej  jednak nie każdemu dane jest dostąpić do tego świętego Grala bo sporo firm używa np svn-a. Sam jestem w takiej sytuacji, że wewnątrz firmy obowiązuje jedyny słuszny svn i nikt nie ma zamiaru zmieniać tego dla jednego marudzącego kolesia. W takiej sytuacji trzeba sobie radzić samemu. Git ma wbudowanego klienta svn-a i nic ale to zupełnie nic nie stoi na przeszkodzie, aby korzystać z niego jako klienta svn.

Do wykonania git-> svn potrzebujemy instalkę gita i tyle.

Uruchamiamy konsolę i odpalamy polecenie

git svn clone https://adres.do.naszego/super/repozytorium/svnowego .

to spowoduje, że cały projekt zostanie zassany do gitowego repozytorium. Ot i cała filozofia. Od tej pory można pracować jak człowiek i przestać marudzić na svn-a (koniec wymówek).

Co do szczegółów. Powyższa komenda pobiera CAŁE repozytorium więc mamy dostępną cała historię (to jest plus), jednak operacja chwilę trwa (minus) – na szczęście jest to jednorazowa operacja (plus).

Ważna inforamcja. Na końcu komenty (po spacji) jest kropa. Ta kropka nie jest przypadkowo. Dodanie jej ściągnie nam tylko trunk-a i nie stworzy podkatalogu trunk. Więc w zależności czy chcesz mieć trunk-a czy nie to dodaj lub usuń kropkę na końcu.

Jest jeszcze jedna metoda, trochę szybsza.

git svn init https://adres.do.naszego/super/repozytorium/svnowego

to stworzy nam puste repozytorium bez pobierania źródeł. To co nam teraz pozostaje to pobrać źródła np. bez historii

git svn fetch –r HEAD

lub bez historii i bez tagów (jeśli twój Build Serwer zakłada tagi przy każdym buildzie)

git svn fetch –r HEAD –ignore-paths=”^tags”

zresztą –ignore-paths=”^tags” można też dodać jako parametr pierwszej komendy (git svn clone …. .).

Mając swoją kopię svn-owego repozytorium możemy pracować zgodnie z workflowem gitowym jaki Tobie odpowiada.

Do pełnej używalności pozostają nam dwie dodatkowe komendy:

git svn rebase (robi update z svna) oraz git svn dcommit (wysyła commity do svn-a).

Tym sposobem mamy narzędzie, w którym możemy pracować zupełnie offline w stosunku do svn-a, możemy pracować na branch-ach, możemy robić commity lokalne i dowolnie kształtować nasz kod a na koniec wypchnąć całość do svn-a.

Osobiście pracuję tak, że w gałęzi master w ogóle nie pracuję. Wszystko co robię, robię w gąłęzi dev i/lub bledy. Następnie przed wrzuceniem zmian do svn-a robię w gałęzi master git svn rebase co pobiera mi zmiany w repozytorium. Za pomocą rebase-a zmiany z gałęzi dev wrzucam do gałęzi master i później git svn dcommit wypycham zmiany spowrotem do svn-a. Plus takiego rozwiązania jest taki, że w svn-ie historia zmian jest cały czas ładna liniowa i nie ma żadnych commitów typu merge (gdybym zamiast rebase korzystał z merge). Z punktu widzenia współpracowników na repozytorium w ogóle nie widać, że gdzieś tam zagnieździł się git. Jedyne co może wzbudzać podejrzenie to 10-20 commitów w odstępach 5-20 sekundowych (ninja dev ;P)

Co do samych narzędzi do git-a to poza SourceTree o którym pisałem wcześniej najwygodniej pracuje mi się w konsoli (o dziwo) ale nie w tej konsoli git-owej tylko w posh-git -cie Uśmiech