MSBuild nie chce robić publish-a

Jest serwer Continuos Integration, który pilnuje, żeby nasz cudny kod był buildowalny poza maszyną developera. To bardzo ważne jeśli tego developera akurat nie ma w biurze. Wiadomo – u dev-a wszystko działa i wszystko się builduje – to czego nie wiadomo to co on/ona mają na komputerach poinstalowane i dlaczego tak naprawdę to to się builduje.

Jak napisałem wcześniej mamy serwer CI, który za nas robi buildy i jeszcze sprawdza czy ładny kod piszemy. Tylko, że testowy serwer ręcznie trzeba było aktualizaować – bez sensu. Wprawdzie to tylko jeden publish w visual studio więc jedną komendą jesteśmy wstanie to zrobić (przechodzimy Test Joela w tej kwestii) to jednak robienie tego ręczne jest po prostu… niepotrzebne. Niechaj CI sam zrobi publisha.

Parę kliknięc w TeamCity i jest.

…cisza. Build przeszedł, TeamCity świeci na zielono, wersja na serwerze testowym jest stara. Szybki rzut oka do loga i… nic.

Na serwerze jest wszystko co potrzebne do buildowania ale dalej TeamCity nie zgłasza błędów z MSBuilda. Po prostu MsBuild wykonuje się poprawnie mimo, że nie robi publisha. Zresztą w logu MsBuilda magicznie nie znalazłem informacji, że publish się nie wykonał. Więcej, nie znalazłem informacji że MsBuild robił publish. Ot, nic takiego nie było. WHAAT!!

Instalacja .net framework 4.5 SDK też nie pomogła. W czeluściach internetów jednak znalazlem, żeby przenieść z maszyny developerskiej katalog

c:\program files (x86)\msbuild\microsoft\visualstudio\v12

do

c:\program files (x86)\msbuild\microsoft\visualstudio\v12

na serwerze buildowania.

Run i… nagle wszystko pięknie działa. Team City robi publish i świat już jest piękniejszy. Aby zrobić publish wersji do środowiska testowego, opublikować instalkę, wrzucić ja na sieć, nazwać i coś tam jeszcze zrobić muszę wykonać komendę:

git svn dcommit

Nowy rok, nowe postanowienia

Zmienił się rok, niby nic specjalnego, ot, umowna data kiedy to wszyscy mamy być szczęśliwi i radośni aby później blogi mógł zalać potok sukcesów w zeszłym roku i postanowień na Nowy Rok.

Moje postanowienia są osobiste, więc nie będę się nimi tutaj dzielił, sukcesy i porażki – no cóż, przez moją opieszałość w pisaniu minął czas i teraz to musztarda po obiedzie. Dzisiaj mamy najbardziej depresyjny dzień roku, kumulacja złamanych noworocznych postanowień z nadchodzącym terminem płatności kredytówek (czyżby przypadkiem płatność za okres obejmujący święta?) czyli blue monday. Z tej okazji zdradzę mój tajny, super sekretny sposób na dotrzymywanie postanowień noworocznych dzięki któremu zarobiłem miliony spełniłem 9 z 14 zeszłorocznych postanowień. Całkiem niezły wynik szczególnie, że przepis jest super prosty.

Właściwie składa się z 2 rzeczy.

1) Zapisz postanowienia noworoczne. Jak do wszystkich list tak i do tej używam Wunderlist, który się synchronizuje ze wszystkim co się rusza więc zawsze swoje listy mam przy sobie.

2) Ustaw w kalendarzu comiesięczne przypomnienie, że należy sprawdzić listę postanowień. Używam do tego google calendar z przypomnieniami na sms.

Tyle i aż tyle. Zapisanie postanowień powoduje, że jasno i klarownie mamy napisane co chcemy uzyskać. Bez ściemy, że się coś zapomniało. Sami przed sobą możemy się rozliczyć. Drugi krok po prostu nie pozwala zapomnieć. Co miesiąc mamy przypomnienie i możemy wykreślić to co zostało zrealizowane a co nie, oraz co ważniejsze skorygować kierunek i usunąć te postanowienia, które są bez sensu. Wiadomo, takowe się trafiają; czasem życie weryfikuje listę i niektóre wypadają. Nie ma co nad nimi płakać.

Jeśli już złamałeś/aś swoje postanowienia noworoczne (a wg. statystyki tak właśnie jest) to proponuję 1 lutego zrobić nową listę. 1 luty ma tę przewagę nad 1 stycznia, że nie masz kaca, dzień jest dłuższy a i miesiąc jakby trochę krótszy. Poza tym, ten dzień nie jest bardziej lub mniej szczególny niż 1.01.RRRR+1

ITAD 2014 – OCB z IOT

Prędko, prędko baśń się baje,
nie tak prędko autor staje;

na wysokości zadania i pisze regularnie. Grubo ponad miesiąc minął od ostatniego wpisu (o TDD), działo się w tym czasie sporo. Między innym zostałem zaproszony na IT Academic Day na bielskiej ATH. Tym razem opowiedziałem o Internet of Things. Dokładniej to zrobiłem taki bardzo mały wstęp do tego arcy ciekawego i arcyinterdyscyplinarnego tematu. Standardowo dostałem ostatni slot czyli z jednej strony najlepszy bo można zanegować wszystko co mówili przedmówcy no i pozostają tylko ci najbardziej zainteresowani z drugiej strony – najgorszy slot bo już wszyscy chcą iść do domu. Presja czasu jest spora. Z tego względu umknęły mi dwie rzeczy:

1) wyszukiwarka IoT:

https://thingful.net/

Znajdziecie tutaj sporo urządzeń, które są wpięte do sieci. Ogrom dostępnych urządzeń pokazuje jaki potencjał drzemie w IoT a należy zaznaczyć, że to nie są wszystkie urządzenia. IMHO to jest grubo poniżej 1%. To pokazuje, jaki potencjał drzemie w tym temacie. Szczególnie warto zwrócić uwagę na Polskę, widać, że na naszym podwórku jest sporo do zagospodarowania.

2) Jawbone + withings + nest

O tych trzech urządzeniach wspominałem w prezentacji i to dosyć mocno bo wszystkie bardzo mi się podobają zarówno ze względu na funkcjonalność, którą oferują jak i na wygląd. Moja estetyka. To o czym jednak zapomniałem wspomnieć, to to, że można te trzy urządzenia zintegrować. Jeśli jawbone wykryje, że słabo śpimy – że za krótko jesteśmy w głębokiej fazie snu w czasie, której de facto odpoczywamy i się regenerujemy; do tego withings stwierdzi, że jest za ciepło to nest może po prostu obniżyć trochę temperaturę.

Brzmi jak bajka? Ale nie jest – podobno. Podobno bo nie przetestowałem tego osobiści, mój jawbone i withings są w drodze a piec, którego używam ma termostat białkowy, z którym NEST nie jest kompatybilny. Bajka bajką, odpowiednia ilość technologii może wyglądać jak magia ale dla nas – developerów – nie ma w tym nic nadzwyczajnego. API + API + API i kawałek w miarę prostej logiki i możemy taką integrację zbudować. To jest dla mnie całe piękno IoT. Połączenie urządzeń i api jakie dają + internetu lub choćby intranetu. Jak zwał tak zwał, ważne, że urządzenia mogą ze sobą gadać. Kawałek kodu wsadzony choćby w malinkę potrafi to wszystko ożywić i wtedy zaczyna się magia.

Co do samego ITAD BB to jestem pod sporym wrażeniem, niby konferencja studencka, na uczelni, organizowana przez kółko zapaleńców siedzenia po nocach przed ekranem w celu przestawiania literek i cyferek – a jednak Ci zapaleńcy zebrali >300 ludzi, całkiem sporo firm i jeszcze więcej nagród. Miałem okazję być na “poważnych konferencjach” gdzie było mniej osób. Kudos! no i oby tak dalej.

A wracając do mojej prezentacji, to jeśli ktoś był i ma jakikolwiek feedback to chętnie wysłucham.

Jeszcze słowo o TDD

O TDD napisano wiele, sam napisałem całkiem sporo i mówiłem całkiem sporo podczas kilku prelekcji. Używam TDD od ponad 5 lat już. Powinienem być super mega ninja pro TDD master. Mimo tego jakiś czas temu, pisząc bardzo prosty kod, na prawdę super prosty, naszła mnie taka refleksja:

Jest zielone, jest ok.

[Fact]
public void Example_test()
{
    _pinger.Ping().Returns(c =>
    {
        throw new Exception();
    });
    Assert.DoesNotThrow(()=>_monitor.CheckAvaliability());
    _destinationSystem.Received(1).Ping(Arg.Is<IDiagnostics>(diag => diag.State == ""));
}

Powyższy kawałek kodu używa NSubstitute (.Ping().Returns(c=>…..) do mockownia. Oraz XUnit-a do testów. Napisałem test jak wyżej, napisałem kod. Niby wszystko zielone, niby ok. Jakimś cudem jednak pokusiło mnie, żeby dorzucić AutoData. AutoData to taki sprytny atrybut, który pozwala generować dane testowe. W moim przypadki Message z wyjątki ma znaczenie, dlatego stwierdziłem, że Message można spokojnie generować – tutaj kod jest taki, że mam pudełko, które jak zrobi coś złego to to złe ma wyjść z drugiej strony – case dla AutoData jak malowany.

[Theory,AutoData]
public void Example_test(string exceptionMessage)
{
    _pinger.Ping().Returns(c =>
    {
        throw new Exception(exceptionMessage);
    });<
    Assert.DoesNotThrow(()=>_monitor.CheckAvaliability());
    _destinationSystem.Received(1).Ping(Arg.Is<IDiagnostics>(diag => diag.State == exceptionMessage));
}

No i zonk!!! Test już nie bardzo to przechodzi. Pomyślałem, bez jaj, przecież implementacja jest tak prosta, że tego nie da się zepsuć – nawet nie wiem po co pisałem na to test, ale nie uprzedzajmy faktów…. Debug testu i….. okazało się, że jednak w kodzie gdzie łapię wyjątek, to oprócz logowania tak jak to powinno być to już message-a  nie przepisuję. Kto by pomyślał.

Testy jednostkowe nie dają 100% gwarancji, że powstanie kod bez bugów, nie dają nawet jakiejkolwiek gwarancji, co jednak dają, to dużo wyższą szansę, że powstały kod będzie miał mniej bugów niż bez testów. W moim przypadku, okazało się, ze prosta refaktoryzacja – lub bez AutoData dodanie kilku przypadków testowych, pozwoliła złapać buga zanim kod poszedł na produkcję.

Cena darmochy ciąg dalszy

tools

Szybko czas leci i od ostatniego wpisu minął prawie kwartał. Nawet nie wiem kiedy. W poprzednim wpisie marudziłem na FireBirda – pseudo bazę danych. Ciekawą polemikę podjął Gutek w swoim wpisie. Nie mogę się zgodzić jednak z

takie rzeczy mają prawo się dziać, w końcu, i tak mamy dostęp do naprawdę całkiem spoko bazy danych. A co w przypadku rzeczy które są „prawie” darmowe?

FireBird jest darmowy jednak nie do końca. Wymaga on pracy developera a ta kosztuje realne pieniądze. Zresztą:

nazywam „prawie” darmowe rzeczy, które są darmowe do ściągnięcia i nawet na siłę da się w nich za darmo programować, ale nie jest to już takie proste

No właśnie, praca z FireBirdem prosta nie jest co pokazał Michał Jawulski pokazując mi jak ustawić transakcje, żeby można było zrobić rename tabeli – sorry nie rename bo tego do  tej pory nie wiem jak zrobić – delete i recreate. Nie wspominając o 1=0 – ciągle mnie to zadziwia. To co mnie jednak najbardziej zadziwia to

Spójność danych

Okazuje się, że w FireBirdzie można w dla kolumy powiedzmy X która zawiera kilka nuli to tu to tam, dodać constraint not null. FireBird nie powie słowa. Ot doda not null constraint dla kolumny. Wszystko pięknie gra bo już nie wrzucimy nowego rekordu z nullem w kolumnie X i nikomu zupełnie nie przeszkadza, że w not null jest jednak null  (w starych danych). WOW ale najlepsze jest jak się zrobić backup – bo się zrobi. Tyle tylko, że już restore nie zadziała (podobno bo nie sprawdzałem osobiście – jak ktoś potrafi jednak użyć takiego backupa to proszę przemówić).

Złośliwy programista

No właśnie, co jeśli budując program w jakimś defaultowym słowniku programista niby przypadkowo, niby złośliwie, ot tak, wrzuci jakiś jeden null a potem doda not null i taką bazę będzie redystrybuował ze swoją aplikacją? Baza będzie nierestorowalna, więc w sytuacji ekstremalnej, gdzie admin w swojej niekompetencji nigdy nie sprawdzi czy restore działa, pewnego dnia obudzi się z zepsutą bazą i bez backupów (które mógł by użyć)….

… dlatego FireBird w mojej ocenie to pseudo baza, której powinno się unikać jak się da.