Raspberry Pi2 i nowe media center

Jeśli ostatni tydzień spędziłeś pod kamieniem to pewnie nie wiesz, że na świat przyszła nowa wersja malinki, raspberry pi 2. Mamy teraz do dyspozycji 1GB ramu oraz 4 rdzenie. Spora różnica w porównaniu do poprzedniej wersji. Rozmiar jak i cena bez zmian. Jeśli dowiedziałeś się o tym czytając tego bloga to na prawdę musisz mieszkać w jaskini bo o tym wydarzeniu napisali już wszyscy – może poza pudelkiem i mną do teraz.

IMG_20150203_185617

Wszyscy pisali bo i jest o czym pisać, Microsoft ogłosił, że będzie wspierał raspberry Pi 2 swoim Windowsem 10, czekam na to bo może być wesoło. Ciekawe jak będzie działał na tym .net bo do tej pory uruchamiałem na malinie mono i nie miałem większych problemów z tym.

Media Center

Pierwsza malina, która zawitała do mnie do domu pracowała jako media center czyli RaspBMC + dysk zewnętrzny. Spokojnie hostowała sobie zdjęcia, filmy, trochę muzyki, radia internetowe, youtuby i takie tam inne. Ot smart tv w domowym wykonaniu. Demonem prędkości nigdy nie była ale też nie można było bardzo na nią narzekać. Nowe Raspberry Pi 2 na piewszy ogień ma zamienić stary model B (bez plusa) i dać kopa. Tylko, że Raspbmc nie działa z Pi2, na stronie jest oficjalna informacja, że nie ma już wsparcia. Projekt raspbmc jest niejako martwy bo Sam Nazarko (autor) skupia się na nowej platformie OSMC i to działa już na Pi2 i działa super szybko.

OSMC to na razie alpha. więc i choroby wieku dziecięcego się pojawiły. Pierwsza to brak sieci. Przez interfejs użytkownika nie działało u mnie ustawianie sieci – a chcę mieć statyczne ip na tym. Aby to obejść wystarczy wyłączyć ui – opcja wyłącz (bez restartu) i za pomocą esc możemy dostać się do konsoli tam już logowanie (nowe defaultowe hasło daje wam osmc i user osmc) i można brać się za konfigurację.

vi… nie działą, vim też nie, ale działą nano

niestety /etc/network/interfaces też nie działa bo osmc używa jakiegoś innego lepszego sposobu używania sieci, google mówi, że:

sudo nano /var/lib/connman/ethernet.config

i wpisujemy

[service_ethernet]
Type = ethernet
IPv4 = 192.168.1.100/255.255.255.0/192.168.1.1
Nameservers = 192.168.1.1

Czyli generalnie konfiguracja, w postaci

IPv4 = ip malinki/maska/gateway
Nameservers = dns

Restart i śmiga wszystko jak złoto. Jest internet, jest ssh, można szaleć.

I jeszcze jedna uwaga, Pi2 u mnie zaczął wyświetlać kolorowy tęczowy kwadrat na ekranie, czyli brakowało mu mocy z zasilacza. Działa stabilnie ale marudzi, że słabo. Ładowarka od Nexus-a 4 to dla niej za mało dlatego wymieniłem na ładowarkę z iPhone-a i już nie marudzi.

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