Kilka dni temu Micorosft wypuścił Update 2 dla Visual Studio 2012. Kilka dni minęło, więc można instalować, pomyślałem sobie. Instalacja przeszła raz dwa, myślę .. musi działać 🙂
Wziąłem się do dalszej pracy i pech chciał, że akurat jeden UnitTest zapalił się na czerwono. Uzbrojony w ReSharper’a namierzyłem trefny test, klikam na zielone kółeczko obok testu “Debug”, czekam ….
TFS: Checked-out identical files
Okazuje się, że w tak zarąbistym narzędziu jakim jest TFS, można łatwo i bez trudu wykluczyć wszystkie pliki, których nie tknęliśmy, ale nasz wspaniały source control tool potraktował je jako zawierające “nasze zmiany”. Mimo, że jeśli tylko spróbujemy porównywać ów plik, z tym na serwerze, to sam przyzna, że są one identyczne.
StatLight i ClientAccessPolicy
Ostatnio bawię się TFSem i automatycznymi buildami. Jednym z kroków w procesie jest odpalenie unit testów pod Silverlighta.
Na stronie pyxis-tech.com można znaleźć świetny poradnik, jak można to zrobić przy użyciu narzędzia o nazwie “StatLight“.
Silverlight & async unit testing
W pracy mamy aplikacje, która jest pisana w Silverligtcie. Ostatnio trafiła do mnie potrzeba napisania unit testa do pokrycia command’a z ViewModela. Niestety, sam command wykorzystuje pewne dane słownikowe, które wcześniej aplikacja sobie zaczytuje asynchronicznie z WCF’a.
W projektach, w których dotychczas uczestniczyłem asynchroniczność była wykorzystywana na niskim poziomie i w zasadzie, nigdy nie miałem przyjemności i okazji do napisania testu pod coś co łączy się w takim trybie. Dodatkowo dane słownikowe winny się były załadować na początku unit testu w metodzie inicjalizującej, ponieważ chciałem je móc wykorzystać w kilku testach.
Pluralsight – hardcore developer training ;)
Jakiś czas temu, podczas sesji wroc.NET udało mi się zdobyć miesięczną wejściówkę na Pluralsighta ( taaak, warto przychodzić na spotkania grupy! 😉 ), choć nie była to niestety licencja na R#, na którą polowałem od dawien dawna ;>
Z wroc.NET do dotnet-zentral ;)
Będąc ciałem i duchem we Wrocławiu bardzo lubiłem uczęszczać na spotkania Wrocławskiej Grupy .NET‘owej. Tematyka raz była mniej interesująca, innym razem bardziej .. jednak to co mi się najbardziej podobało, to możliwość spotkania się i podyskutowania z innymi pasjonatami .NET’a, którzy często po spędzeniu 8 i więcej godzin w pracy byli w stanie i chcieli spędzić jeszcze dodatkowe 2-3 godziny siedząc wśród sobie podobnych, słuchać i wymieniać się wiedzą.
Jeszcze zanim wyjechałem z Wrocławia, zacząłem szukać społeczności .NET’owej w nowym miejscu zamieszkania. Z jednej strony chciałem sobie zapewnić możliwość ciągłego rozwoju za granicą, dwa że jest to bardzo fajna opcja na rozbudowanie swojej sieci kontaktów ( o tym jeszcze wspomnę kiedy indziej ).
Po dłuższych poszukiwania udało mi się znaleźć całkiem młodą grupę – dotnet-zentral w Luzern. ( niestety grupa w Zurichu kiedys istniala, ale padła z nieznanych mi przyczyn).
Co prawda Luzern jest położone troszeczkę dalej od Zurichu, ale z połączeniami kolejowymi tutaj jest to niecała godzina drogi – często porównywalnie tyle samo czasu schodziło mi, żeby samochodem przebić się przez korki z pracy na spotkanie grupy we Wrocławiu ;).
Richtung Zurich
Pod koniec lutego po prawie 10 latach spędzonych we Wrocławiu opuściłem to miejsce by udać się na dobrowolną emigrację 😉 Powody były czysto prywatne, choć marzenie “zawsze chciałem pożyć parę lat za granicą” też tu dorzuciło swoje 5 groszy 😉
Decyzja nie była łatwa, bo ciężko jest bądź co bądź wyjechać z miejsca, w które się dość mocno wrosło przez tych kilka lat… – rodzina, znajomi ze studiów, z pracy, wroc.net, ogródek działkowy pod blokiem 😉
Kiedyś, jeden ze znajomych z wroc.NET, gdy pracowaliśmy jeszcze w poprzedniej firmie stwierdził:
“jedyne co mnie tu trzyma oprócz znajomych to rachunek za Internet”
… 😉 i kurcze miał rację!
Swoją drogą, mój anonimowy nieistniejący czytelniku, gdybyś szukał kiedykolwiek fajnej firmy programistycznej we Wrocławiu, o zdrowym podejściu do programisty, ze spłaszczoną strukturą zarządzania to śmiało uderzaj do Objectivity 😉 tam raz dwa poczujesz się, że jesteś “wsród swoich” 🙂
Przepis: Paczki
Zawsze w okresie około tłusto czwartkowych przychodzi człowiekowi ochota na faworka bądź na pączka.
Jeżeli jeszcze się okaże, że znajduje się on w miejscu, gdzie o dobrego pączka naprawdę trudno, wyjściem okazuje się zrobienie ich samemu (pomijam tu kwestię czy własny pączek będzie lepszy od pączka sklepowego; akurat nie miałem żadnej alternatywy 😉 )
Moja wczorajsza myśl była prosta – “aaa to tylko kilka godzin zabawy i brzucha napełnię pączkiem” – życie niestety pokazało, że nie do końca… 🙂
Dlatego mocne postanowienie na przyszłość:
Nie będę zabierał się za robienie pączków:
* w ciągu tygodnia pracującego -.-‘ Alee z tym długo schodzi 😐
* bez robota kuchennego, robótka ręczna sux 🙂
* bez domowych konfitur – bo w sklepie dobre ciężko dostać :/
Przepisów na pączki jest wiele, poniżej ten, który od wielu lat wykorzystuje się w mojej rodzinie.
Zasadzka na wyjątka!
Czasami zdarza sie, że aplikacja wraca z testów bo tester popsuł aplikację i gdzieś leci mu wyjątek.
Czasami zdarza się, że sami popsujemy naszą aplikację i gdzieś nagle leci wyjątek.
Czasami od razu wiemy, które miejsce “przecieka”, kiedy indziej musimy chwilę poszukać.
Niestety, również czasami zdarza się, że pomimo tego, że wiemy gdzie jest dziura, ciężko nam jest namierzyć konkretny moment gdy dziad jest rzucany (np. dana metoda wykorzystywana jest w wielu różnych przypadkach).. no zdarza się..szukanie i gdybanie sprawia, że zadanie jest coraz mniej przyjemne.
Okazuje się, że w Visual Studio mamy możliwość na zasadzenie się na konkretny typ wyjątka.
Przy pomocy skrótu klawiszowego “Ctrl+Alt+E” ( tudzież Debug->Exceptions ), możemy wywołać okienko “Exceptions“, które pozwala nam na zasadzenie się na konkretny, bądź wszystkie rodzaje wyjątków w naszej aplikacji.
Taka fajna opcja, niby jest tam od zawsze, a czasem wogóle nie wykorzystywana.
Wykrzaczajaca sie kontrolka w designerze.
Przy okazji ostatniego spotkania Wroclawskiej Grupy .NET przypomnial mi się jeden myk, który swego czasu ułatwił mi znacząco życie.
Czasami zdarza sie, ze projektując kontrolkę tudzież formularz wykorzystujący różne nasze kontrolki, ta z różnych tylko sobie znanych powodów się nam czasem wykrzacza gdy chcemy ją podejrzeć w designerze.
W znalezieniu błędu może pomóc nam prosty trik:
Otwieramy drugie Visual Studio (#B#) z tą samą solucją i podłączamy się pod proces pierwszego Visual Studio (#A#) (w okienku “Attach to process” będziemy widzieć proces drugiego visual studio, więc nie podłączymy się sami pod siebie 🙂 )
Następnie w Visual Studio #A# otwieramy jeszcze raz naszą formatkę z kontrolka i przechodzimy do podglądu designera.
W momencie, gdy kontrolka rzuca obrzydliwym wyjątkiem, Visual Studio #B# zatrzymuje się nam dokładnie w miejscu, z którego leci wyjątek 🙂
Voilà!